Java Client Side Application Basics: Decompiling, Recompiling and Signing

Transcription

1 Java Client Side Application Basics: Decompiling, Recompiling and Signing Written By: Brad Antoniewicz

2 Introduction... 3 Java Web Start and JNLP... 3 Java Archives and META-INF... 4 Getting Started... 4 JDK Quick Install... 5 Downloading and Extracting... 5 Dealing with Signed JARs... 6 Decompiling... 7 Recompiling and Re-JARing... 7 Signing the JAR... 8 Making it work... 9 Enabling Verbose logging within Java... 9 Conclusion More Information... 11

3 Introduction One of the major rules of security is Never trust client side security. Somehow this rule is often forgotten, especially when companies deploy client side Java applications. They can try their best to obfuscate every part of code, but in the end, its all run on the client side, which means the user has the ability to control everything. This brief document will teach you the first steps of picking apart the contents of a client side Java application, and hopefully lead you on your way to some great findings. Java Web Start and JNLP Java Web Start is a mechanism for program delivery through a web server. These programs are initiated by the client s web browser, deployed, and ultimately executed independently on the system. Since they run outside of the browser, security may appear to be an initial concern, however the application runs within a restricted container (called a sandbox), which sits atop of the Java 2 platform s security architecture. This provides a couple nice layers of security between the application and the local machine. The Java Network Launch Protocol (JNLP) is an XML-based technology for launching Java executables. The.JNLP file is basically the Table of Contents for the Java application; most importantly, for our use, it defines the location of application resources. This file is what we re usually directed to when accessing a Java Web Start application. Example JNLP: java_app.jnlp <?xml version="1.0" encoding="utf-8"?> <jnlp codebase=" href="java_app.jnlp"> <information> <title>super ClientSide APP v1.0</title> <vendor>not Real INC</vendor> <icon kind="splash" href="logo.jpg" width="200" height="60"/> </information> <security> <all-permissions/> </security> <resources> <!-- Requires J2SE or higher --> <j2se version="1.4.2*" href=" <j2se version="1.5+"/> <jar href="inc/app-core.jar"/> <jar href="inc/app-gui.jar"/> <!-- Properties --> <property name="banner.colour" value="black"/> <property name="module.1.name" value="model"/> <property name="module.1.class" value="com.fakecompany.model"/>

4 <!-- Disable DNS caching to allow Wide IP failover/load balancing --> <property name="networkaddress.cache.ttl" value="0"/> </resources> <application-desc main-class="com.fakecompany"/> </jnlp> Java Archives and META-INF A Java Archive (JAR) is a file format based on the popular ZIP file format. In its most basic form, it is a compressed archive containing all of the Java class files (which we will decompile) of the application. It also contains one very important directory: META-INF. At a minimum, this directory contains the MANIFEST.MF. The JAR s manifest contains package and extension related data. An important thing to remember is that when the JAR is signed, MANIFEST.MF will also contains SHA1 hashes of every file within itself. This means if we ever want to modify a class within the archive and maintain valid signatures, we ll have to completely recompile the JAR and resign it rather than just updating it. Also inside the META-INF folder of signed archives is a signature file (.SF) and its corresponding block file (.DSA). When we recompile our JAR, we ll remove the META-INF folder entirely so that there is little to no trace of the initial company who signed it. Getting Started Since the JNLP is simply a XML file, we can download this file to get a list of all the JARs which comprise the application. Using the above java_app.jnlp example, we can see that this application is comprised of two JARs: app-core.jar and app-gui.jar. These two files will be extracted, and their contents decompiled so that we can further understand the way they work. Two important things we ll need to install to accomplish our mission will be the Java Development Kit (JDK), and the Java Decompiler (JAD). They can be found using the below links: JDK JAD Installation for both is relatively simple. Follow their instructions and it should be a snap. These can both be set up on Windows, but it is highly recommended to do this on a Linux box somewhere. Depending on the way application was written, it is possible to have multiple classes within the JAR whose filenames are case sensitive. For example, take a look at these two filenames: aa.class and Aa.class. Since Windows does not consider case in the filenames, it will overwrite aa.class with Aa.class, which can completely destroy our application. Linux, however does take the case of filenames into consideration, so that is why it is heavily recommended. All commands given below will be specifically for use under Linux; however it is possible they may work on Windows as well.

5 JDK Quick Install Once you have downloaded the JDK, installation is relatively painless. Follow the below installation procedure. We ve snipped the majority of the output, but most of it is not really important anyway. Nonetheless this should give you enough information. Installing the Java Development Kit Sun Microsystems, Inc. Binary Code License Agreement for the JAVA 2 PLATFORM STANDARD EDITION DEVELOPMENT KIT 5.0 SUN MICROSYSTEMS, INC. ("SUN") IS WILLING TO LICENSE THE SOFTWARE IDENTIFIED BELOW TO YOU ONLY UPON THE CONDITION SNIPED --. Creating jdk1.5.0_10/jre/lib/charsets.jar Creating jdk1.5.0_10/jre/lib/ext/localedata.jar Creating jdk1.5.0_10/jre/lib/plugin.jar Creating jdk1.5.0_10/jre/lib/javaws.jar Creating jdk1.5.0_10/jre/lib/deploy.jar Done. root@jdkdemo:/home/user# mv jdk1.5.0_10/ /usr/local root@jdkdemo:/usr/local# cd /usr/local root@jdkdemo:/usr/local# ln -s jdk1.5.0_10/ jdk root@jdkdemo:/usr/local# export PATH=$PATH:/usr/local/jdk/bin Downloading and Extracting We ve identified which JARs make up the application using the JNLP file, and now we ll need to download and extract them. Following our example, we ll execute the following commands to download our JARs: Downloading the JARs root@jdkdemo:/home/user# wget root@jdkdemo:/home/user# wget

6 Now you ll have the two JARs in your current directory, and they ll need to be extracted. Extracting the JARs mkdir app-gui cp app-gui.jar app-gui cd app-gui jar xf app-gui.jar rm app-gui.jar cd.. mkdir app-core cp app-core.jar app-core cd app-core jar xf app-core.jar rm app-core.jar cd.. Obviously, the only command that needs to be executed is the jar xf jarfile.jar, but I added all the extra commands so we can have a nice neat directory structure. Dealing with Signed JARs Now we ll need to determine if our JARs are signed or not. We can do that in one of two ways. The easiest way at this point is to just check within the decompiled JAR and see if there is a.sf in the META-INF directory. If there is, then the JAR is signed, and we ll need to resign. Alternately you can do the following: Identify if the JAR was signed root@jdkdemo:/home/user/app-gui# jarsigner verbose certs verify app-gui.jar root@jdkdemo:/home/user/app-core# jarsigner verbose certs verify app-core.jar This will give you a good amount of information if the JAR is actually signed. If it does not, then most likely the JAR is not signed and it will state that clearly near the bottom of the command output. As mentioned above, it is important to determine if the JAR was signed because with a signed JAR, the MANIFEST.MF will contain a SHA1 digest of each file within itself. If we update a particular file, the digest will not match the one in the MANIFEST.MF, and the application may fail to run (again, this is only if the JAR was signed). Also if we recompile and re-sign any one particular JAR, we are required to recompile and resign every other JAR that is specified within the same JNLP. Finally, it is not uncommon for the Java application to require complete access to the local system through the <all-permissions> security directive. If this directive is set, the JAR must be signed.

7 Decompiling Now that we have extracted the JAR and identified if it has been signed, our next step is to decompile whichever classe(s) we d like to investigate. This is where JAD comes in. JAD s usage is very simple and straightforward. You can decompile everything within a certain directory, source tree, or an individual file. JAD does not decompile JAR files directly so you need to extract the JAR first as detailed above. We would recommend dissecting everything for your investigation. Later on, if you plan on modifying something specifically, re-extract the JAR and only decompile that particular class as it makes things less complicated with the recompile. You can also avoid these complications by decompiling to completely different directory. Decompiling Individual files root@jdkdemo:/home/user/app-gui/classes# jad classfile.class Decompiling All files within Directory root@jdkdemo:/home/user/app-gui/classes# jad *.class Decompile all class files within a source tree to a different directory, renaming them to.java files root@jdkdemo:/home/user/app-gui/classes# jad r sjava d/home/user/app-gui/src /home/user/appgui/classes/*.class By default JAD will output a.jad file for the source code that can be read or modified. JAD can also decompile directly to.java files by using the s option. The destination for source files can be set with d, and the package directory structure is restored with r. Other JAD options can be displayed by calling jad with no arguments. The application s source is now available for you to dissect and investigate. If there is a particular function that is getting in your way by making some obscure check, why not take it out! The power is yours! It may be a good idea to make a minor change in the logging portion of the application, and you can verify that it s working through the Java logging console. One quick note, if you re making any changes, remove the original.class and leave the.java in the same directory. If you decompiled to a different directory, after you modify it, copy the.java over to the compile directory when ready to recompile. It will make the recompile process smoother. Recompiling and Re-JARing The task of recompiling is nearly as simple as that of decompiling; however we ll need to make an important change: removing the META-INF. As mentioned above, the META-INF directory contains a couple

8 goodies that are particular to the JAR. Since we re recompiling the entire archive, we can take it out, as it will be added automatically when we recompile. Here are our steps for recompiling and rejaring. We took a hypothetical file, classfile.java (was decompiled with JAD) within the gui/ and core/ directories, respectively. Recompiling and rejaring root@jdkdemo:/home/user# cd app-gui/ root@jdkdemo:/home/user/app-gui# rm classes/classfile.class root@jdkdemo:/home/user/app-gui# javac cp. classes/classfile.java root@jdkdemo:/home/user/app-gui# rm rf META-INF root@jdkdemo:/home/user/app-gui# jar cvf app-gui.jar. root@jdkdemo:/home/user/app-gui# cd../app-core/ root@jdkdemo:/home/user/app-core# rm classes/classfile.class root@jdkdemo:/home/user/app-core# javac cp. clasees/classfile.java root@jdkdemo:/home/user/app-core# rm rf META-INF root@jdkdemo:/home/user/app-core# jar cvf app-gui.jar We removed the preexisting class files as a matter of organization, and so we can verify they were created after the recompiling process. Great! So now we modified our class, recompiled it, and re-jared it. Depending on how the application was initially set up, you could be done! Just give it a run and see if it worked out! However, it s more likely that it was signed, so let s get to the annoying part. Signing the JAR IF YOUR JAD WAS NOT SIGNED TO BEGIN WITH THIS STEP MAY BE SKIPPED! This is the most annoying part of the whole process. Since we obviously cannot resign the JAR using with the originally owners key, we ll have to make our own and then sign it ourselves. The first thing we ll have to do is make a keystore using keytool: Creating a Keystore And Public/Private Key Pair keytool -genkey -keystore mykeystore -alias myalias Enter keystore password: <password> What is your first and last name? What is the name of your organizational unit? What is the name of your organization? What is the name of your City or Locality? What is the name of your State or Province?

9 What is the two-letter country code for this unit? Is CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown correct? [no]: yes Enter key password for <myalias> (RETURN if same as keystore password):[press Enter button] Your keystore has now been created. Look for the file mykeystore in your current directory. Now we can sign the JAR (assuming mykeystore is in the same directory you started in)! Sign the JAR cd app-core/ jarsigner -keystore../mykeystore -storepass <password> app-core.jar myalias cd../app-gui jarsigner -keystore../mykeystore -storepass <password> app-gui.jar myalias Just verify using the jarsigner tool mentioned above and you re ready to put it all into action. Making it work You can go back to your Windows box and do some basic tests to figure out where the application is saving itself once it downloads to your machine. You can use Filemon ( or just simply search for the.jar on your machine (usually in c:\documents and settings\<user>\application data\ ). Once you figure this out, simply replace those with your repacked and resigned JARs. Double click the JNLP to launch the application, and hopefully your modification will work! You may see a Java warning message complaining that the application is signed by an unknown authority, but you can safely ignore that, as you re that unknown authority! Enabling Verbose logging within Java If you made the recommended logging change in the application or you re just curious to investigate the logs of the application, you can make Java display more verbose logging within the Java Control Panel. Enabling Java Logging Within the Windows Control Panel, click the Java icon to display the

10 following window. Navigate to the Advanced Tab Expand the Trees under Debugging and Java Console. Under Debugging, mark the Enable Tracing, Enable Logging, and Show applet lifecycle exceptions checkboxes. Under Java console mark the Show console radio button. Hit OK

11 Conclusion Excellent job! You have successfully decompiled your JAR, figured out how to recompile it, and learned how to resign it if necessary. Now it s up to you to closely analyze the application and figure out what you can to with the decompiled JAR to identify vulnerabilities in the application. The important thing to remember here is that because this is client side, all the power is now in your hands. For example, if the application waits for a server response to validate authentication, try to change that check to automatically return true. This way you can see the application functionality without actually logging in. That s just one very simple idea - go ahead, play around, and most importantly, HAVE FUN! More Information If you re new to Java or would like to get more oriented with Java development, check out the following links: The Java Tutorials OWASP Guide - General Web Application Testing Java Programming Resources Learn More For additional information about Foundstone consulting, please contact your local sales representative: Phone: FOUND Consulting@foundstone.com