2024年1月8日发(作者：)

This is the default wrapping level which provides no protection to your java file. As you can see, the Hide class files andEncrypt and hide class files options are left unchecked. This level of protection simply takes your java archive/jar file,concatenates it to the end of the executable, and embeds its java files inside of it. This java archive can be recovered using ahex editor, just like we did with launch4j in the previous tutorial. To begin, we will open sample file called'' in winhex. To find the archive, scroll to the bottom of the file. Another option you can try other thanscrolling is to search for the ascii string "serial "(with the space). This should take you directly to the archive, but I cannotguarantee that this approach will always be successful.

Once you are here, the first occurrence of 'PK' labels the start of our archive. We can label this as our beginning of block:Once you have done so, right click the selected block and click Edit. In the new pane, go to Copy Block -> Into New ards, we can save it as a jar file. I used the name :Once we are finished, the program will run correctly, but to be tidy, we need to delete the extra files that Jar2Exe added toour archive. Let's open the archive in 7-zip or winrar(whichever you fancy).Once it is opened, you can see that Jar2Exe adds an additional directory called 'com'. While some other java applicationsmay use this directory, Jar2Exe adds an additional subdirectory called entering the com directory, we see that regexlab is the only subdirectory it contains, meaning that the entire comfolder is unused and can simply be deleted from the archive, let's go ahead and delete it:

After confirming the deletion, we can close the archive and run the jar you did everything correctly, the application should run without problems and our work is 2Exe Level 2: Hidden Archive:

With the level 2 protection, Jar2Exe takes our java archive, encrypts it, and adds it as an RCData entry in the resourcedirectory. To find the offset of the encrypted archive, we need to open our executable which I named '' ina resource editor. For this, I prefer resource hacker:

Above, we have located the encrypted data in the "RCData" section of the resource table. In this case, our offset is a note of this and open the application in Ollydbg. Once you have it opened, go to the hex dump section and go to theoffset above:

Once you arrive at the offset, right click the byte and add a Hardware Breakpoint On Access -> Byte:

Now, let's run the program and wait for the break to occur. We should arrive here:This loop will decrypt our archive byte for byte. Let's toggle a breakpoint on the instruction after the loop. In this example,the instruction is 00401BE3 > CMP DWOR PTR SS:[ESP+18],EBP. Run the program now and let the decryption we break here, the register EAX will contain the location where our decrypted jar file is located and ECX contains itssize. Using this information, we are ready to dump the file from memory. To do this, I found a very simple plugin calledMemory Dump. It allows you to simply specify a memory address and size to dump those bytes to disk. Let's open theplugin:To begin, check the field which says End Address / Lenght. This will allow us to enter the length value. Set the Start Addressto the value in EAX and the lenght(length) equal to the value in ECX. In my case, the address is 296810 and the size is11EC. Once you have entered these values, we are ready to dump this to disk.

A limitation of this tool is that you can only save the file with a .dmp extension, but we can easily rename it once we arefinished. Simply save it with the name you fancy. In this case I named it as for easy recognition.

After a quick renaming, the file is ready to run.

Jar2Exe Level 3: Hidden Archive + Encrypted Class Names:

This is the strongest protection offered by Jar2Exe. First, it changes all of the class file names to gibberish. Second, itencrypts and hides the files just like the level 2 protection. While we can recover the archive with a similar method as inLevel 2, we need to take an additional step to repair the class begin, let's open the application "" in a resource editor just as before to acquire the offset of theencrypted RCData:

Our offset in this case is 49398h. Let's note that and open the application in Ollydbg and follow the offset

Once we arrive at the offset, place a hardware breakpoint on access-> byte just like before.

Run the program an wait for the breakpoint. We should arrive at the following code:This is the new decryption routine. The instruction 0040ACED-> MOV BYTE PTR DS:[ECX],AL will move each decrypted byteto their new memory ing to the code, the address of the memory location where our file is decrypted to can be found at the stack pointer[ESP+18]The value at ESP+1C contains the size of the memory region. This can be verified by checking the decrement value of theloop.

This code verifies that ESP+1C is the value decremented. ESP+1c is moved to EAX, decremented, and then moved back.

At our current location where the hardware breakpoint landed us, the values at ESP +18 and ESP+1C are the ones we needfor our dump. Please note them and target a breakpoint on the instruction outside of the you break here, we are ready to make a dump of the file. But first, I would like to show you the encrypted strings inour archive to give you a glimpse of how jar2exe encrypts them:As you can see here, the names of our classes and manifest files have been completely obfuscated. As a result, we need torecover these names manually. The way that jar2exe gets the original names for the class is to read them directly from theclass file itself. I will show you a simple approach to doing this once we dump the since I am finished digressing, let's dump the file just like my case, the location of the decrypted file is at 296858 and its length is 1284. We are ready to dump.

Now that we have saved the file, let's rename change the extension to .jar and prepare to extract the note that due to the encryption employed on the names, the file will not run until we correct the classes. Let's extractthe contents to a new folder so we can begin repairing.

Once we have extracted the files, let's open the new directory and see the files.

As we can see here, the file names are complete gibberish. The randomly named directories will typically not contain a fileand can be deleted. The rest of the files will be the original class and manifest files. To begin the recovery, I like to firstidentify which file is the manifest. We can usually assume that the manifest will be the smallest file contained in the file tells the java runtime which file contains the main() class. Without it, the runtime would not know how toexecute the code. Let's find the smallest file and open it in a text editor.

As you can see, we have identified our manifest file. This file should be renamed to '' and placed in asubdirectory called 'META-INF'. Remember that these names are case sensitive and must be typed in all continue with the rest of the files, let's add a '.class' extension to each of them and open them in your favorite javadecompiler. You can read these names with a hex editor if you fancy, but a decompiler makes it a little cleaner. Let's beginwith the largest file which is 4kb. I will open it in DJ Java DecompilerAs we can see here, we have identified the name of this class file as SimpleApp which according to the manifest, containsour main() procedure. The name of the package this file resides in is 'e'. The dots between thesewords represent a subdirectory. That means that this class belongs in a folder hierarchy of net/sf/launch4j/example. Let'srename this to class file to '', create the directory hierarchy listed above, and place this file in that we have completed this, we just need to go back and follow the same steps for the rest of the files. Pleaseremember that every name is case sensitive. Once you have recovered each of them and placed them into the correctdirectory(there is only one directory), it should look like this:Now that we are done, it is time to recreate the jar file. A jar file is simply a zip archive under a different extension. All weneed to do is go back to the directory that contains our two folders named 'net' and 'META-INF' and add them to a , we simply change the extension of the zip archive to jar and it is ready to run.