Method (1) has big advantage if you are already familiar Java or similar OO-styled languages. However, in practice it has two main drawbacks:
Typically, the targeted jar file has dependencies to other libraries. You should be familiar with linking those dependencies to your project
The decompilation process is not an exact science, so expect to fix syntactical errors before getting it to recompile
On one project after importing a decompiled jar file into Eclipse there are nearly 1000 syntactical errors. Going through and fixing all of it would be a pain, especially what you want to do is just edit a few lines of code.
In this blog post, I want to introduce to you a method (2) of patching Java. It is faster, less error-prone and quite simple to execute. I hope it will be useful for developers that are in need of patching Java. Some potential use cases are:
Patch security issues without original source code
Inject custom code to application
In the example below, I will show you how to patch the JBoss encrypting library to use custom private key to encrypt data source strings.
JBoss has a SecureIdentityLoginModule utility to encrypt data source password in XML configuration files. More info can be found at the JBoss Community Site. In JBoss 7, the module is located in picketbox-4.0.7.Final.jar
The objective is to modify default private key. The key is still in the jar file and you can call the corresponding decode() function of the jar file to decrypt it anyway. Hence for a production system I would recommend switching to use the keystore-based JaasSecurityDomainIdentityLoginModule instead. More information could be found at https://community.JBoss.org/wiki/EncryptingDataSourcePasswords.
Setup the environment
Use JD-GUI to peek into the jar file
Unpack the jar file
Modify the .class file with a Java Bytecode Editor
Repack the modified classes into new archive file
Verify it with JD-GUI
Step 1: Setup the Java environment
Most computers should have the JRE installed by default. For this tutorial, you will need to download and install the latest version of JDK. For this example, I am using JDK 6 update 35.
You may also need to add the JDK bin folder to your PATH environment variable. Upon completion, open up a command line console and type:
The result should look something like this:
java version “1.6.0_35″ Java(TM) SE Runtime Environment (build 1.6.0_35-b10) Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01, mixed mode)
Step 2: Use JD-GUI to peek into the jar file
Bytecode editors typically do not support decompiling Java executables. For that reason, I prefer to use a standalone decompiler to quickly browse decompiled classes and identify potential classes/methods. My favorite tool for this task is JD-GUI (we also need it later on to verify the modified bytecode):
As shown in the picture above, browsing to SecurityIdentityLoginModule reveals the default secret key used to encrypt string.
Step 3: Unpack the jar file
The below commands will create new directory > Copy jar file > Extract all the classes (note that in Windows you can use 7zip to extract them as well)
cd <JBOSS_HOME>modulesorgpicketboxmain mkdir picketbox cp picketbox-4.0.7.Final.jar picketbox cd picketbox jar -xf picketbox-4.0.7.Final.jar
Step 4: Modify the .class file with a Java Bytecode Editor
In this example we need to modify two methods of SecureIdentityLoginModule class: encode() and decode(). Note that the original encryption/decryption methods only work with 16-character key. To keep it simple, I will modify default key “jaas is the way” to “java is the way” to keep the length intact.
Step 5: Repack the jar file
Take the changed class file and repack the jar file
cd picketbox jar -cvf picketbox.jar *.*
Step 6: Verify the changes with JD-GUI
JBE tool has Code Verification feature, but in practice, I found it complains too much . Hence, I use JD-GUI again to verify correctness of the modified jar file.
If there’s any error in the modified class file, JD-GUI will not able to render the new jar file. If things go well, you should see your changes reflected in the patched jar file:
PTaaS is NetSPI’s delivery model for penetration testing. It enables customers to simplify the scoping of new engagements, view their testing results in real time, orchestrate faster remediation, perform always-on continuous testing, and more - all through the Resolve™ vulnerability management and orchestration platform.
We help organizations defend against adversaries by being the best at simulating real-world, sophisticated adversaries with the products, services, and training we provide. We know how attackers think and operate, allowing us to help our customers better defend against the threats they face daily.
At NetSPI, we believe that there is simply no replacement for human-led manual deep dive testing. Our Resolve platform delivers automation to ensure our people spend time looking for the critical vulnerabilities that tools miss. We provide automated and manual testing of all aspects of an organization’s entire attack surface, including external and internal network, application, cloud, and physical security.
Our proven methodology ensures that the client experience and our findings aren’t only as good as the latest tester assigned to your project. That consistency gives our customers assurance that if vulnerabilities exist, we will find them.