Free obfuscate software for linux

Obfuscated Tiny C Compiler (OTCC) is a very small C compiler I wrote in order to win the International Obfuscated C Code Contest (IOCCC) in 2002.

My goal was to write the smallest C compiler which is able to compile itself. I choose a subset of C which was general enough to write a small C compiler. Then I extended the C subset until I reached the maximum size authorized by the contest: 2048 bytes of C source excluding the ;, {, } and space characters.

I choose to generate i386 code. The original OTCC code could only run on i386 Linux because it relied on endianness and unaligned access. It generated the program in memory and launched it directly. External symbols were resolved with dlsym().

In order to have a portable version of OTCC, I made a variant called OTCCELF. It is only a little larger than OTCC, but it generates directly a dynamically linked i386 ELF executable from a C source without relying on any binutils tools! OTCCELF was tested succesfully on i386 Linux and on Sparc Solaris.

NOTE: My other project TinyCC which is a fully featured ISOC99 C compiler was written by starting from the source code of OTCC !

Compilation:

gcc -O2 otcc.c -o otcc -ldl
gcc -O2 otccelf.c -o otccelf

Self-compilation:

./otccelf otccelf.c otccelf1

obfsh is a shell script obfuscator. It is quite flexible and can obfuscate any type of shell script.

The obfuscated script version is printed to stdout. The original script is not modified.

Options:

-c < n >, insert deceiving comments for every n line
-d < n >, insert deceiving code for every n line
-e < n1 >-< n2 >, prepend each line with a random number of spaces ranging
from n1 to n2
-f < file >, file to obfuscate
-g < n1 >-< n2 >+< n3 >-< n4 >, insert gibberish header and footer of n2 lines
long with each line n1 signs long, n3-n4 being range of characters
to generate from. See the manual for more details.
-h, usage and options (this help)
-i, remove blank lines, comments, leading and trailing spaces and tabs
-j < n1 >-< n2 >, insert n1 empty lines for every n2 line
-m, manual
-l, see this script"

ProGuard is a free Java class file shrinker, optimizer, and obfuscator. ProGuard project can detect and remove unused classes, fields, methods, and attributes. It can then optimize bytecode and remove unused instructions.
Finally, it can rename the remaining classes, fields, and methods using short meaningless names. The resulting jars are smaller and harder to reverse-engineer.
More compact jar files also means smaller storage requirements, faster transfer of applications across networks, faster loading, and smaller memory footprints.
ProGuards main advantage compared to other Java obfuscators is probably its compact template-based configuration. A few intuitive command line options or a simple configuration file are usually sufficient. For instance, the following configuration option preserves all applets in a jar:
-keep public class * extends java.applet.Applet
The user manual explains all available options and shows more examples of this powerful configuration style.
ProGuard is fast. It only takes seconds to process programs and libraries of several megabytes. The results section presents actual figures for a number of applications.
ProGuard is a command-line tool with an optional graphical user interface. It also comes with plugins for Ant and for the J2ME Wireless Toolkit.
ProGuard is a Java class file shrinker, optimizer, and obfuscator. The shrinking step detects and removes unused classes, fields, methods, and attributes. The optimization step analyzes and optimizes the bytecode of the methods. The obfuscation step renames the remaining classes, fields, and methods using short meaningless names. The resulting jars are smaller and harder to reverse-engineer.
ProGuard can also be used to list unused fields and methods in an application, and to print out the internal structure of class files.
ProGuard typically reads the input jars (or wars, ears, zips, or directories). It then shrinks, optimizes, and obfuscates them. It then writes the results to one or more output jars (or wars, ears, zips, or directories). The input jars can optionally contain resource files. ProGuard copies all non-class resource files from the input jars to the output jars. Their names and contents remain unchanged.
ProGuard requires the library jars (or wars, ears, zips, or directories) of the input jars to be specified. It can then reconstruct class hierarchies and other class dependencies, which are necessary for proper shrinking, optimization, and obfuscation. The library jars themselves always remain unchanged. You should still put them in the class path of your final application.
In order to determine which code has to be preserved and which code can be discarded or obfuscated, you have to specify one or more entry points to your code. These entry points are typically classes with main methods, applets, midlets, etc.
- In the shrinking step, ProGuard starts from these seeds and recursively determines which classes and class members are used. All other classes and class members are discarded.
- In the optimization step, ProGuard further optimizes the code. Among other optimizations, classes and methods that are not entry points can be made final, and some methods may be inlined.
- In the obfuscation step, ProGuard renames classes and class members that are not entry points. In this entire process, keeping the entry points ensures that they can still be accessed by their original names.
Any classes or class members of your code that are created or invoked dynamically (that is, by name) have to be specified as entry points too. It is generally impossible to determine these cases automatically, but ProGuard will offer some suggestions if keeping some classes or class members appears necessary. For proper results, you should at least be somewhat familiar with the code that you are processing.
ProGuard does handle Class.forName("SomeClass") and SomeClass.class constructs automatically. The referenced classes are preserved in the shrinking phase, and the string arguments are properly replaced in the obfuscation phase. With variable string arguments, it is generally impossible to determine their possible values (they might be read from a configuration file, for instance).
However, as mentioned, ProGuard will note constructs like "(SomeClass)Class.forName(variable).newInstance()". These might be an indication that the class or interface SomeClass and/or its implementations may need to be preserved. You can then adapt your configuration accordingly.
Whats New in 3.9 Stable Release:
- This release fixes a number of bugs.
- Notably, ".class" constructs compiled in Java 6 are now handled correctly.
- The optimization step now avoids a possible division by 0 and correctly processes local variables with indices larger than 255.
- The documentation and examples have been updated.
Whats New in 4.0 Beta Development Release:
- Added preverifier for Java 6 and Java Micro Edition, with new option -dontpreverify.
- Added new option -target to modify java version of processed class files.
- Made -keep options more orthogonal and flexible, with option modifiers allowshrinking, allowoptimization, and allowobfuscation.
- Added support for configuration by means of annotations.
- Improved shrinking of unused annotations.
- Added check on modification times of input and output, to avoid unnecessary processing, with new option -forceprocessing.
- Added new options -flattenpackagehierarchy and -repackageclasses (replacing -defaultpackage) to control obfuscation of packages names.
- Added new options -adaptresourcefilenames and -adaptresourcefilecontents, with file filters, to update resource files corresponding to obfuscated class names.
- Now respecting naming rule for nested class names (EnclosingClass$InnerClass) in obfuscation step, if InnerClasses attributes or EnclosingMethod attributes are being kept.
- Added new inter-procedural optimizations: method inlining and propagation of constant fields, constant arguments, and constant return values.
- Added optimized local variable allocation.
- Added over 250 new peephole optimizations.
- Improved making classes and class members public or protected.
- Now printing notes on suspiciously unkept classes in parameters of specified methods.
- Now printing notes for class names that dont seem to be fully qualified.
- Added support for uppercase filename extensions.
- Rewritten class file I/O code.
- Updated documentation and examples.

ccovinstrument package contains instruments C/C++ code for test coverage analysis.

SYNOPSIS

ccovinstrument code.c > covcode.c
ccovinstrument code.c [-f] -o covcode.c [-e errs]
-f instrument fatal code as well as normal code

Scans C/C++ source (before cpp) and inserts trip-wires in each code path to record execution.

A number of error prone coding styles are also detected. Many of these ideas came from study of the highly regarded perl5 source code (and from my own coding experience.

This approach (or almost any approach) to coverage analysis is NOT fullproof! Just because you exercise every code path does NOT mean you have exercised all possibilities. For example, consider the following code:

char
fetch_char(int xx)
{
static char *string = "Dr. Zorph Trokien";
if (xx < 0) {
return 0;
} else {
return string[xx];
}
}

Unfortunately, you still have to be somewhat intelligent about designing your test scripts. However, assuming youre clever, you can use this tool to know when to stop writing more tests. Thus, thereby achieving test coverage.

CCov SOURCE DIRECTIVES

/* CCov: off */
Turns off coverage instrumentation. You probably dont want to analyze debugging code.

/* CCov: on */
Turns on coverage instrumentation.

/* CCov: jump if for do while else return */
Adds to the list of identifiers that cause a change in execution flow. In addition to the usual keywords, macros used by the perl core and XSUBs are included by default.

/* CCov: fatal myexit croak panic */
Adds to the list of identifiers that cause a fatal exception. Instrumentation of these blocks is turned off by default. (You usually want to make sure the code is suppose to work works before you make sure that the code that isnt support to work works.)

HOW DOES IT WORK?

The instrumenter processes source code before it is seen by cpp. This helps you isolate your testing. Usually, you want to do test analysis on each library/application individually. A global analysis would cause you to test new code and all the libraries you are using (for every single application!).

The instrumentor does not really use a lexer (tokenizer). The techniques are probably more similar to image processing than parsing. As you might imagine, this doesnt work in the general case. CCov tries to be forgiving, but it simply doesnt understand obfuscated code. Rather than calling it a bug, I think its an significant feature.

Simple code probably has fewer bugs than complex code. Not only is this tool aimed at test coverage analysis, it is also helps you improve your coding style. There are still some rough edges, but I am mostly satisfied with the degree of strictness.

This package makes it easy to read and write java classfiles. It doesnt, however, provide any help with displaying the contents of a classfile to the user (unless you count debug output), or disassembling the bytecodes.

This code snippet will read in a classfile and write it back out to a different file.

InputStream is = new FileInputStream("Foo.class");
OutputStream os = new FileOutputStream("FooCopy.class");
ClassInfo classInfo = new ClassInfo();
new ClassFileReader().read(is, classInfo);
classInfo.setName("FooCopy"); // Java requires the class name to match the file name
new ClassFileWriter().write(classInfo, os);
is.close();os.close();

The package can read "obfuscated" classfiles, like those generated by Crema, but it cant write them. Obfuscated classfiles have invalid data in them and the only reason they work is because most VMs ignore the data thats invalid (attributes like SourceFile, LineNumberTable, and LocalVariableTable). If a ClassFileReader encounters invalid data, it just ignores it.

Sunifdef is a command line tool for simplifying the preprocessor conditionals in C/C++ source code (#if and related directives) based on the the users chosen interpretation of the preprocessor symbols.
Sunifdef is a more powerful successor to the FreeBSD unifdef tool. Sunifdef is most useful to developers of constantly evolving products with large code bases, where preprocessor conditionals are used to configure the feature sets, APIs or implementations of different releases.
In these environments, the code base steadily accumulates #ifdef-pollution as transient configuration options become obselete. Sunifdef can largely automate the recurrent task of purging redundant #if-logic from the code.
Installation:
Download the tarball to a location under your home directory
Extract the directory sunifdef from the tarball. Do not rename it.
To install from source:
Open a command console and cd into the sunifdef directory
Run ./configure
If all is well, run make
If all is well, run su and enter the root password when prompted (to become root).
Run make install
To install the pre-built executable:
As root, copy built-bin/sunfidef from the sunifdef directory into /usr/local/bin.
Set permissions on /usr/local/bin/sunifdef to make it executable.
As root, copy man/sunifdef.1 from the sunifdef directory into /usr/local/man/man1
To test that Sunifdef is installed:
Run sunifdef -v, and expect output like:
sunifdef, version 0.1.3 (built Feb 22 2006, 19:47:48)
sunifdef: Completed, exit code 0x0000
Run man sunifdef, and expect to see the sunifdef man page.
Enhancements:
- The parser is strengthened to cope with contexts that were formerly skipped over as "obfuscated".
- The --obfusc option is thus redundant and is withdrawn.
- Six bugs are fixed.
- The demise of the Sourceforge compile farm means that many platforms can no longer be tested for this release.

mailto.php reclaims HTML mailto: links from spammers e-mail address harvesters. Using JavaScript, it creates a link to an e-mail address while keeping the actual address obfuscated.

mailto.php turns this:

< a href="mailto:user@host.com">user@host.com< /a>

into

< script language="JavaScript"
type="text/javascript">eval(unescape(%76%61%72%20%61%64%64%72%20%3
d%20%27%25%36%61%25%36%66%25%36%34%25%37%32%25%36%35%25%36%63%25%36%63%25%34%30%
25%37%33%25%37%30%25%36%66%25%36%34%25%32%65%25%37%35%25%36%62%25%32%65%25%36%65
%25%36%35%25%37%34%27%3b%76%61%72%20%73%74%72%69%6e%67%20%3d%20%27%25%36%61%25%3
6%66%25%36%34%25%37%32%25%36%35%25%36%63%25%36%63%25%34%30%25%37%33%25%37%30%25%
36%66%25%36%34%25%32%65%25%37%35%25%36%62%25%32%65%25%36%65%25%36%35%25%37%34%27
%3b%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%20%68%72%65%66%3d%2
2%6d%61%69%6c%74%6f%3a%27%20%2b%20%75%6e%65%73%63%61%70%65%28%61%64%64%72%29%20%
2b%20%27%22%3e%27%20%2b%20%75%6e%65%73%63%61%70%65%28%73%74%72%69%6e%67%29%20%2b
%20%27%3c%2f%61%3e%27%29%3b));< /script>

Which is pretty hard for e-mail gathering programs to decode.

mailto.php has been tested in all major browsers, including Mozilla, NS4, IE, Opera and Konqueror.