Free binary translator software for linux

SNMP Trap Translator is an SNMP trap handler written in Perl for use with the NET-SNMP and UCD-SNMP snmptrapd program. Received traps are translated into friendly messages using variable substitution.
Output can be to STDOUT, text log file, syslog, NT Event Log, MySQL (Linux/Windows), PostgreSQL, or an ODBC database. User defined programs can also be executed.
Many network devices including but not limited to network switches, routers, remote access servers, UPSs, printers and operating systems such as Unix and Windows NT have the ability to send notifications to an SNMP manager running on a network management station. The notifications can be either SNMP Traps, or SNMP Inform messages.
The notification can contain a wide array of information such as port failures, link failures, access violations, power outages, paper jams, hard drive failures etc. The MIB (Management Information Base) available from the vendor determines the notifications supported by each device.
The MIB file contains TRAP-TYPE (SMIv1) or NOTIFICATION-TYPE (SMIv2) definitions, which define the variables that are passed to the management station when a particular event occurs.
Enhancements:
- Various database improvements have been added such as support for proper date/time data types, statistics logging, and custom columns.
- The formatting for unknown_trap_exec can now be changed.
- Support has been added to MATCH for bitwise AND.
- A new log file has been added for logging system messages to a text file for users without access to syslog.
- Various bugs have been fixed, including support for Net-SNMP 5.4 traphandle, a daemon mode PID file, REGEX captures, MATCH modifiers, and others.

SigTranslator is a project able to translate IDS signatures e.g. from Snort rules to Dragon rules and vice versa. SigTranslator can translate as well the common signatures standard (CIDSS - Common Intrusion Detection Signatures Standard).
Signature Translator is simple to use Java application which will help you to use signatures in your favourite IDS translated from other IDS .
Enhancements:
- Major code enhancements and bugfixes.

BinaryKlock project is a binary clock kicker applet.

The special thing about this clock is that it displays the time in binary instead of using the decimal system.

Binary is pretty easy to read and many people will nonetheless stare at your desktop, not believing how you can read the time from that.

This is my first KDE application, let me know if you like it ;)

Building:

This is my first KDevelop project as well, and Im not yet extremely familiar with it. It generated the usual autoconf files and you should be able to build it like this:

./configure
make
make install

The Java Binary Enhancement Tool (JBET) is a general Java program analysis and manipulation tool. Existing class files can be disassembled, reassembled, or edited programmatically through the JBET API. JBET can also be used to create new Java class files from scratch. JBET uses a convenient internal representation of all the contents of Java binary (.class) files, allowing the user to edit the classes easily, in a structured manner.

JBET was developed as part of the DARPA Self-Protecting Mobile Agents project under the OASIS and Active Networks programs (contract number N66001-00-C-8602) in order to study automated software obfuscation.

The Java language was chosen for this project because of the (relative) ease of constructing binary editing tools provided by the large amount of type information present in the class files. Our two reports, the Obfuscation Techniques Evaluation Report, and the Obfuscation Report, are available from the download area. The obfuscation tool developed is not part of this release.

JBET was also used in the DARPA/AFRL Survivable Server project (contract number F30602-00-C-0183) to add additional security checks to the Java Standard Library. (The Java SecurityManager API does not support many desirable security checks, such as continued authorization of file accesses after opening.)

JBET was used to replace the native method references in the Java standard library with stubs that call a pluggable security policy. This tool, called Jpolicy, is also available for download at this website. Jpolicy is very incomplete at this time, but may be interesting to those working in Java security or changing the standard library themselves.

The internal representation of Java class files used by JBET is intented to make it easy for programmers to write Java binary code transforms. Each element of Java class files has a corresponding internal data structure: ClassInfo for entire classes, MethodInfo for methods, FieldInfo for fields, Snippit for code blocks, and Instruction for individual instructions. Snippit and Instruction understand Java opcode syntax and semantics, allowing automated creation of valid Java programs. A Java-compatible class verifier is also included.

Some code transforms are difficult to program directly by manipulating Java instructions. For those transforms, a directed acyclic graph (DAG) representation of code is available. In the DAG representation, each basic block has a corresponding DAG, with a set of input and output nodes. Edges in the graph connect "producer" nodes (such as constants, or the result of calculations) to "user" nodes (such as method calls or other calculations). Methods are divided into basic blocks and control flow is stored at the basic block level (possible because Java has only fixed jump targets)

JBET requires a Java 1.4 virtual machine to run, although it can operate on class files from earlier Java versions. The packaging and build environment supplied supports Linux and Windows with Cygwin; however, the build process is simple and could be performed manually on other platforms. Perl is required for regression testing.

Jpolicy requires a Java 1.4 virtual machine to build, either Linux or Windows NT/XP with Cygwin. gcc is required for building on Windows (supplied with Cygwin). The runtime system can be either Java 1.3 or 1.4 (with Suns JVM only), running on Linux or Windows NT/XP. Windows 9x and Windows 2000 may work as well, but have not been tested.

Installation

1. Install jdk 1.4.1.
2. Set CLASSPATH to jdk1.4.1/jre/lib/rt.jar
3. cd src; make
4. If that didnt work, examine the makefile. java or javac may not be in the path.
5. To build a jar file that can be used with "java -jar jbet.jar", run "make jar".
6. If you have perl installed, run the tests with "make test".
Optionally, run "make regen; make test".

Make a symbolic link from jbet3/bin/jbet to somewhere in your path.

Usage

JBET uses the JNI format for class names, and JNI type and method descriptors. For a summary of this syntax, use jbet help syntax. Suns JVM specification may also be helpful.

To look at a class disassembly, use jbet print. Try disassembling a class you have source for, and was built with debug info (-g): jbet -P < classpath > print < classname >. Suns JVM specification has an instruction reference.

SQL::Translator::Manual is a Perl module that contains a manual for SQL translator.

SYNOPSIS

SQL::Translator (AKA "SQLFairy") is a collection of modules for transforming (mainly) SQL DDL files into a variety of other formats, including other SQL dialects, documentation, images, and code. In this manual, we will attempt to address how to use SQLFairy for common tasks. For a lower-level discussion of how the code works, please read the documentation for SQL::Translator.

It may prove helpful to have a general understanding of the SQLFairy code before continuing. The code can be broken into three conceptual groupings:

Parsers
The parsers are responsible for reading the input files and describing them to the Schema object middleware.

Producers
The producers create the output as described by the Schema middleware.

Schema objects
The Schema objects bridge the communication between the Parsers and Producers by representing any parsed file through a standard set of generic objects to represent concepts like Tables, Fields (columns), Indices, Constraints, etc.

Its not necessary to understand how to write or manipulate any of these for most common tasks, but you should aware of the concepts as they will be referenced later in this document.

Tree::Binary::Search is a binary search tree for Perl.

SYNOPSIS

use Tree::Binary::Search;

my $btree = Tree::Binary::Search->new();

$btree->useNumericComparison();

$btree->insert(5 => "Five");
$btree->insert(2 => "Two");
$btree->insert(1 => "One");
$btree->insert(3 => "Three");
$btree->insert(4 => "Four");
$btree->insert(9 => "Nine");
$btree->insert(8 => "Eight");
$btree->insert(6 => "Six");
$btree->insert(7 => "Seven");

# this creates the following tree:
#
# +-------(5)----------+
# | |
# +-(2)-+ +-(9)
# | | |
# (1) (3)-+ +----(8)
# | |
# (4) (6)-+
# |
# (7)
#

$btree->exists(7); # return true

$btree->update(7 => "Seven (updated)");

$btree->select(9); # return Nine

$btree->min_key(); # returns 1

$btree->min(); # returns One

$btree->max_key(); # return 9

$btree->max(); # return Nine

$btree->delete(5);

# this results in the following tree:
#
# +-------(6)-------+
# | |
# +-(2)-+ +-(9)
# | | |
# (1) (3)-+ +-(8)
# | |
# (4) (7)
#

This module implements a binary search tree, which is a specialized usage of a binary tree. The basic principle is that all elements to the left are less than the root, all elements to the right are greater than the root. This reduces the search time for elements in the tree, by halving the number of nodes that need to be searched each time a node is examined.

Binary search trees are a very well understood data-structure and there is a wealth of information on the web about them.

Trees are a naturally recursive data-structure, and therefore, tend to lend themselves well to recursive traversal functions. I however, have chosen to implement the tree traversal in this module without using recursive subroutines. This is partially a performance descision, even though perl can handle theoreticaly unlimited recursion, subroutine calls to have some overhead. My algorithm is still recursive, I have just chosen to keep it within a single subroutine.

Scriptol to binary Compiler is a C++ native compiler.

Installation:

It is better to install Scriptol at root of a disk, for example:
c:scriptolc

Once the archive is extracted into the scriptolc directory, you have just to change to this directory to run the compiler.

To use the compiler at command line from any directory, you have to put the compiler into the path variable.

The setup script installs required file into sub-directories, or into the directory given as argument. Before to use the compiler, you have to read the licence, in the doc
directory: licence.html.

Usage:

Just type:
./solc mysource

Type "solc" only to list the options.

If your program is a multi-file project, the source given as parameter must be the main source file, the compiler will know dependencies from "include" statements and will build what is needed.

Exemples:

Type from the main scriptol directory:
./solc -bre demosfibo

Configuring:

By editing the solc.ini file, you may change the second pass compiler (you may have to rebuild the libsol library for this compiler), change the options of the compiler or add header files to include.

To add header files, just add "header=someheader.hpp" lines into the config file.

A xxx.cfg file may be written for each project main source beeing xxx, and if present, it overloads the solc.ini file.