yGuard is a free Java bytecode obfuscator and shrinker that improves your software deployment by prohibiting unwanted access to your source code and drastically shrinking the processed Jar files at the same time.

Features

• yGuard is absolutely free! Contrary to expensive commercial products of our competitors providing the same amount of features as yGuard or less, yGuard is free.


• yGuard is an Ant task! Existing tools use proprietary mechanisms to invoke or configure the task of obfuscation. As an Ant task, yGuard can be seamlessly integrated into your deployment process using XML syntax.


• yGuard provides highly configurable name obfuscation that will protect your intellectual property from reverse engineering.


• yGuard provides elaborate code shrinking functionality through dependency analysis.


• yGuard 2.0 offers a new powerful and easy to use XML syntax that allows the effortless definition of code entities e.g. based on pattern sets or inheritance.


• yGuard will correctly obfuscate and shrink programs that depend on external libraries.


• yGuard can automatically rename and adjust textual resource files according to the obfuscation scheme.


• yGuard can scramble and unscramble or shrink line number table information. This means that debugging an obfuscated program is still achievable without weakening the obfuscation.


• yGuard can create patches! During each obfuscation run, yGuard produces XML output that can be used to create subsequent patches of already deployed obfuscated applications.


• yGuard supports JDK 1.5 features and correctly obfuscates classes compiled with its new features.

Why Use yGuard?

• Name Obfuscation: protects your .class files from reverse engineering by replacing package, class, method, and field names with inexpressive characters. If afterwards the obfuscated .class files are decomplied, it will be extremely diffcult to derive the original purpose of the obfuscated code entities.
  As an additional side-effect, name obfuscation will significantly reduce the size of your application, depending on the chosen mapping scheme.


• Code Shrinking: drastically reduces the size of the input Jar files if your application does not use all of the contained bytecode.
  The shrinking engine analyzes the bytecode of all input Jar files in order to determine which code entities can not be reached from a set of given code entry points. These obsolete code fragments (either entire classes or single methods and fields) will then be removed by yGuard. If you use any third party libraries, you will probably benefit a lot from the yGuard shrinking engine, since applications usually do not use all of the functionality provided by an external library and a large fraction of the contained bytecode and resources can be safely removed.

Eclipse has many features that make the job of a programmer easy. Here a simple project is created and will use few of those features to demonstrate how easy programming can be using Eclipse. Most of the new programmers, ignore these and prefer to code everything themselves which is time consuming.

1. First creating a package: really simple. Right click the project name and click “ New ” – > “ Package” . Name it as “car” .







2. Creating a class in it named “ Car ” and defined 2 private attributes namely “ doors ” , “ seats ” . Now generate getters/setters for that. Eclipse can generate those for us. In the Source menu, click “ Generate getters and setters ” .








3. Now make another class in the same package named “ Honda ”. Create a “ main ” method in this class. Eclipse will generate “ main ” method once you check the “ generate main method ” checkbox while creating the class.


4. Also to make Car class to be the superclass for “ Honda ” class. Click “ Browse ” button against superclass field of the class declaration window. As “ Car ” class is under package “ cars ”, parent class for Honda will be “ cars.Car ”.

Eclipse will generate the following code:

package cars;public class Honda extends Car {

 

/**

 

* @param args

 

*/

 

public static void main(String[] args) {

 

// TODO Auto-generated method stub

 

}

 

}

In class Honda, following lines of code are added.

	Car car1 = new Honda(); car1.setSeats(4);

 

car1.setDoors(2);

 

System.out.println(car1.calcNum());

“ car1.calcNum() ” shows error as this method is not declared in the class Car. One way is to go back to class Car and declare the method. Simple way is to click the red cross on the left of the problem line and Eclipse will give you the options for automatically generating the required method in the required class. After generating the required method, Write code according to the requirement in the generated method.

Review the code:

package cars;public class Car {private int doors;private int seats;

 

public int getDoors() {

 

return doors;

 

}

 

public void setDoors(int doors) {

 

this.doors = doors;

 

}

 

public int getSeats() {

 

return seats;

 

}

 

public void setSeats(int seats) {

 

this.seats = seats;

 

}

 

public Object calcNum() {

 

return this.getDoors() * this.getSeats();

 

}

 

}

 

package cars;

 

public class Honda extends Car {

 

public static void main(String[] args) {

 

Car car1 = new Honda();

 

car1.setSeats(4);

 

car1.setDoors(2);

 

System.out.println(car1.calcNum());

 

}

 

}

One of the good features of Eclipse is its auto fill property. This can be further enhanced using its code template feature. Creation of code templates is necessary to improve development productivity. Templates add consistency and uniformity to your code. Eclipse has so many ready-to-use templates. And you can create your own code templates according to your requirements. To use these templates just type the starting characters of the template and then press “CTRL+SPACE”. For example in Ecipse IDE type “tr” and then press “CTRL+SPACE”, It will add “try-catch” block to the code.

This article will guide you to create your own code template. Let us take an example to generate a “if-else” template with one “else if” condition.

1. Go to the Templates ( Window –> Preference –> java–> Editor –> Templates) .


2. Click “New”. A window similiar to below appears.







3. Fill the details as shown above.


4. Click “OK”.


5. Now you can use your custom template in the program like any other template by pressing “CTRL+SPACE” as shown in the below given screenshots.

Eclipse Integration

yWorks Ant Explorer is available as a plugin for the popular Java IDE Eclipse. It supports both the visualization and execution of Ant build scripts.

Installation

You can install the plugin by using Eclipse’s integrated Update Manager, which is available via the menu items “Help” – “Software Updates” – “Find and Install.”
A “New Remote Site” with URL “http://www.yworks.com/eclipse/update” has to be created.

Alternatively, the Jar archive containing the Eclipse plugin can be directly downloaded and extracted into the respective directory (normally, %ECLIPSE_HOME% or ${user.home}/.eclipse).

Usage

The views of yWorks Ant Explorer are opened whenever the visualization of an Ant build script is started via its menu item from the “Package Explorer.”

Furthermore, the views are automatically updated whenever they are visible and an Ant build script is opened inside the editor view.

The visualization view comprises two parts; one view holds the graph that displays dependencies between targets, whilst the other view displays the properties. Edges between properties denote that they are being used in other properties.

Further information for each view can be found in our documentation.

Restrictions

• Build processes are executed inside the same JVM that runs Eclipse.
  This can lead to side effects, for example regarding the class path or open file handles, etc.
  For problematic build scripts, we recommend that you use the yWorks Ant Explorer stand-alone version instead.


• “Unesthetic” Icons
  Unfortunately, Eclipse Version 3.0.1 cannot render transparent PNGs in the menu bar. Lower-quality GIFs are used to replace them.

Distributing your Application as an executable JAR file

A JAR (Java ARchive) is a way of packaging together all of the resources associated with a program (class files, images, sounds, etc.). Putting your program in a JAR allows it to be distributed as a single executable file, saving space and simplifying the download process. The information in this tutorial applies to Java version 1.2 or higher. For more information about JAR files, follow Sun’s tutorial. To learn about signing the JAR and Java Web Start.

A simple example. Let’s say we wanted to distribute the simple program Hello.java as a JAR. First, we create a text file named Hello.mf which contains:

Manifest-Version: 1.0

Main-Class: Hello

jar cmf Hello.mf Hello.jar Hello.class Hello.java

java -jar Hello.jar

Creating an executable JAR file. Here is the general procedure for creating an executable JAR:

1. Compile your java code, generating all of the program’s class files.
   



2. Create a manifest file containing the following 2 lines:
   

   Manifest-Version: 1.0
   
   Main-Class: name of class containing main
   
   

   The name of the file should end with the .mf suffix. It is important that the file ends with a blank line.
   



3. To create the JAR, type the following command:
   

   jar cmf manifest-file jar-file input-files

   The input-files must include any class files, images, sounds, etc. that your program uses. Optionally, you can include the program’s .java files in the JAR. See below for adding directories ot the JAR.
   



4. To view the contents of the JAR, type:
   

   jar tf jar-file

   
   



5. Execute the application from the command line by typing:
   

   java -jar jar-file

   If the application is GUI-based, you can also launch it by double-clicking the JAR file.

Accessing resources in a JAR. In general, the first step in accessing a JAR resource involves creating a URL. This might require modifying your program. For example, you can no longer use the following code fragment to read in an image that is stored in a file as follows

Image image = Toolkit.getDefaultToolkit().getImage(filename);

URL url = getClass.getResource(filename);

Image image = Toolkit.getDefaultToolkit().getImage(url);

URL url = X.class.getResource(filename); 

JAR Subdirectories. The JAR format also support storing files in a directory structure. Consider a program Sample.java, which uses the Turtle Graphics interface to display a collection of pictures stored in a subdirectory called images. Our working directory looks like:

The Manifest should read:

Manifest-Version: 1.0

Main-Class: Sample

To create the JAR, type:

jar cmf Sample.mf Sample.jar Sample.class Turtle.class Sample.java Turtle.java images

The contents listing appears as:

META-INF/

META-INF/MANIFEST.MF

Sample.class

Turtle.class

Sample.java

Turtle.java

images/

images/image1.gif

images/image2.gif

images/image3.gif

Notice that the directory structure is still preserved (the META-INF directory is created to hold the manifest and other general information about the JAR).

You may need to include package version information in a JAR file’s manifest. You provide this information with the following headers in the manifest:

Headers in a manifest

Header	Definition
Name	The name of the specification.
Specification-Title	The title of the specification.
Specification-Version	The version of the specification.
Specification-Vendor	The vendor of the specification.
Implementation-Title	The title of the implementation.
Implementation-Version	The build number of the implementation.
Implementation-Vendor	The vendor of the implementation.

One set of such headers can be assigned to each package. The versioning headers should appear directly beneath the Name header for the package. This example shows all the versioning headers:

Name: java/util/

Specification-Title: Java Utility Classes

Specification-Version: 1.2

Specification-Vendor: Sun Microsystems, Inc.

Implementation-Title: java.util

Implementation-Version: build57

Implementation-Vendor: Sun Microsystems, Inc.

For more information about package version headers, see the Package Versioning specification .

An Example

We want to include the headers in the example above in the manifest of MyJar.jar.

We first create a text file named Manifest.txt with the following contents:

Name: java/util/

Specification-Title: Java Utility Classes

Specification-Version: 1.2

Specification-Vendor: Sun Microsystems, Inc.

Implementation-Title: java.util

Implementation-Version: build57

Implementation-Vendor: Sun Microsystems, Inc.

---

Warning : The text file must end with a new line or carriage return. The last line will not be parsed properly if it does not end with a new line or carriage return.

---

We then create a JAR file named MyJar.jar by entering the following command:

jar cmf MyJar.jar Manifest.txt MyPackage/*.class

This creates the JAR file with a manifest with the following contents:

Manifest-Version: 1.0

Created-By: 1.6.0 (Sun Microsystems Inc.)

Name: java/util/

Specification-Title: Java Utility Classes

Specification-Version: 1.2

Specification-Vendor: Sun Microsystems, Inc.

Implementation-Title: java.util

Implementation-Version: build57

Implementation-Vendor: Sun Microsystems, Inc.

The Java^TM platform enables you to digitally sign JAR files. You digitally sign a file for the same reason you might sign a paper document with pen and ink — to let readers know that you wrote the document, or at least that the document has your approval.

When you sign a letter, for example, everyone who recognizes your signature can confirm that you wrote the letter. Similarly when you digitally sign a file, anyone who “recognizes” your digital signature knows that the file came from you. The process of “recognizing” electronic signatures is called verification.

The ability to sign and verify files is an important part of the Java platform’s security architecture. Security is controlled by the security policy that’s in force at runtime. You can configure the policy to grant security privileges to applets and to applications. For example, you could grant permission to an applet to perform normally forbidden operations such as reading and writing local files or running local executable programs. If you have downloaded some code that’s signed by a trusted entity, you can use that fact as a criterion in deciding which security permissions to assign to the code.

Once you (or your browser) have verified that an applet is from a trusted source, you can have the platform relax security restrictions to let the applet perform operations that would ordinarily be forbidden. A trusted applet can have freedoms as specified by the policy file in force.

The Java platform enables signing and verification by using special numbers called public and private keys. Public keys and private keys come in pairs, and they play complementary roles.

The private key is the electronic “pen” with which you can sign a file. As its name implies, your private key is known only to you so that no one else can “forge” your signature. A file signed with your private key can be verified only by the corresponding public key.

Public and private keys alone, however, aren’t enough to truly verify a signature. Even if you’ve verified that a signed file contains a matching key pair, you still need some way to confirm that the public key actually comes from the signer that it purports to come from.

One more element, therefore, is required to make signing and verification work. That additional element is the certificate that the signer includes in a signed JAR file. A certificate is a digitally signed statement from a recognized certification authority that indicates who owns a particular public key. A certification authority are entities (typically firms specializing in digital security) that are trusted throughout the industry to sign and issue certificates for keys and their owners. In the case of signed JAR files, the certificate indicates who owns the public key contained in the JAR file.

When you sign a JAR file your public key is placed inside the archive along with an associated certificate so that it’s easily available for use by anyone wanting to verify your signature.

To summarize digital signing:

• The signer signs the JAR file using a private key.


• The corresponding public key is placed in the JAR file, together with its certificate, so that it is available for use by anyone who wants to verify the signature.

Digests and the Signature File

When you sign a JAR file, each file in the archive is given a digest entry in the archive’s manifest. Here’s an example of what such an entry might look like:

Name: test/classes/ClassOne.class

SHA1-Digest: TD1GZt8G11dXY2p4olSZPc5Rj64=

The digest values are hashes or encoded representations of the contents of the files as they were at the time of signing. A file’s digest will change if and only if the file itself changes.

When a JAR file is signed, a signature file is automatically generated and placed in the JAR file’s META-INF directory, the same directory that contains the archive’s manifest. Signature files have filenames with an .SF extension. Here is an example of the contents of a signature file:

Signature-Version: 1.0

SHA1-Digest-Manifest: h1yS+K9T7DyHtZrtI+LxvgqaMYM=

Created-By: 1.6.0 (Sun Microsystems Inc.)

Name: test/classes/ClassOne.class

SHA1-Digest: fcav7ShIG6i86xPepmitOVo4vWY=
Name: test/classes/ClassTwo.class

SHA1-Digest: xrQem9snnPhLySDiZyclMlsFdtM=
Name: test/images/ImageOne.gif

SHA1-Digest: kdHbE7kL9ZHLgK7akHttYV4XIa0=
Name: test/images/ImageTwo.gif

SHA1-Digest: mF0D5zpk68R4oaxEqoS9Q7nhm60=

As you can see, the signature file contains digest entries for the archive’s files that look similar to the digest-value entries in the manifest. However, while the digest values in the manifest are computed from the files themselves, the digest values in the signature file are computed from the corresponding entries in the manifest. Signature files also contain a digest value for the entire manifest (see the SHA1-Digest-Manifest header in the above example).

When a signed JAR file is being verified, the digests of each of its files are re-computed and compared with the digests recorded in the manifest to ensure that the contents of the JAR file haven’t changed since it was signed. As an additional check, digest values for the manifest file itself are re-computed and compared against the values recorded in the signature file.

You can read additional information about signature files on the Manifest Format page of the JDK^TM documentation.

The Signature Block File

In addition to the signature file, a signature block file is automatically placed in the META-INF directory when a JAR file is signed. Unlike the manifest file or the signature file, signature block files are not human-readable.

The signature block file contains two elements essential for verification:

• The digital signature for the JAR file that was generated with the signer’s private key


• The certificate containing the signer’s public key, to be used by anyone wanting to verify the signed JAR file

Signature block filenames typically will have a .DSA extension indicating that they were created by the default Digital Signature Algorithm. Other filename extensions are possible if keys associated with some other standard algorithm are used for signing.