Unpacking Launch4j 3.5: Extracting The Jar File

Unpacking Launch4j 3.5: Extracting The Jar File:

Welcome to this short tutorial for unpacking Launch4j. Launch4j is a Java executable wrapper for Windows which makes the process of deploying a Java application on windows a little less arduous. It bundles the Java application with all of its command line arguments into a single executable and passes itself directly to the java runtime or "java.exe" upon execution. The goal of this tutorial is to show you how to recover/extract/unpack the original jar file and retrieve the command line arguments from the executable. While most protection detecting utilities do not detect launch4j, it is quite easy to identify this wrapper by using string references to find the string 'Launch4j'.

The application we will be working with is the demo project included with Launch4j called SimpleApp. It is located in the Launch4j installation directory in the folder '%Launch4j%\demo\SimpleApp\'. To begin, we will open our file 'SimpleApp.exe' in LordPE and click the sections button. This window will allow us to determine the Raw Offset and size of the resource section which usually has the name '.rsrc'.   

 As we can see in the picture, the raw offset is '6000h' and its raw size is '1C00h'. The jar file is always located directly after the end of the last section and spans all the way until the end of the file, so '6000h + 1C00h= 7C00h'. This means that 7C00h is the raw offset of the Jar file. Let's open the application up in winhex to verify.

As you can see here, we have reached the beginning of the Jar archive which is indicated by the 'PK' file type identifier. As stated above, the end of the archive will be the last byte in our file. In order to make sure we select everything correctly, we need to mark this offset as the 'beginning of block' through the right click menu.

Once you have done this, we can simply scroll to the last offset and mark it as the 'end of block'. 

This will automatically select all of the bytes in our archive and allow us to extract and save them as another file. To do this, right click the selection and click the 'Edit' button.

From here, another menu will appear. Go to the option 'Copy Block' and in the sub-menu, click 'Into New File'.

Afterwards, a save dialog will appear. In this example, I decided to name the file 'SimpleApp2.jar'.

After clicking save, let's run our extracted file and see the results.

As you can see, our extraction was successful and the file runs correctly, so our work is done. 

While this file runs correctly as is, in some cases, the author may pass additional command line arguments to the java runtime. If we do not recover these parameters, some applications may not run correctly.  To do so, we can open the original file in ollydbg and set a breakpoint on the API CreateProcessA. After running the application, we will shortly break here and we can read the arguments off of the stack. Below, we can look at the following example from another target.

In this example, we can can see that application is passing the parameters -Xms256M and -Xmx800M which tells the application the minimum and maximum ram amount to allocate to the process. Without these parameters, the application may not have the ram it requires to perform certain tasks. That is why it is crucial to recover these parameters to insure that the extracted jar will work correctly. 

Another approach to recovering these parameters would be to search for them with a resource editor. While this approach may not be as reliable as the one above, it may be best when working with malicious code.

In this example, I was able to find the parameters stored in the RC Data directory of the resource table. 

I hope that you were able to walk away with some new knowledge. If there is something that you are not quite able to grasp or understand, please feel free to post your questions or comments below. Until next time, happy reversing.