So I renamed this function and looked around xrefs, I found a vtable and, surprise, the decryption function that we reverse earlier is in it !
I quickly linked a string to the executable from the source code, and the function around it looks like the same code Probably the main program, I don’t understand why they used this old code in the jar2exe stub I search on google some strings and I found this old weard chinese source codeĪpparently, this code is comming from an old encryption tool from 2002 So they probably used a library to achieve this, I look up about the strings and searched “Crypt” because in general, libraries like this leak a lot of string and patterns in the code. They will not reinvent the wheel if the goal of this wrapper is to execute Java code.
While I was watching the decryption code, I was thinking that it was too complex to be created by there people. But I want to understand how this function work, So I will continue to reverse it. So from this, we can rush to the JAR File in memory and unpack it. And after its call, will be filled with the decrypted content. So we are sure that this function decrypt our JAR File. Sub_4110C0 ( DWORD * this, char * PTR_RCDATA, BYTE * OUTPUT_BUFFER, int SIZE_OR_RCDATA ) I renamed some resource related objects and we can notice that the function also store the size of the Encrypted JAR File. I will switch to pseudo code to show you a more trivial representation of the code. This pointer is stored in a register that will be used only one time, so we can think that the decryption process is made around here. This ResInfo handle is used here with the LockResource funtion that lock the resource for others thread and return the encrypted content pointer in memory. And here, we found one call that used the same id as our Encrypted JAR File resource. In particular the FindResourcesA that return a ResInfo handle of a given resource id. We just have to follow them to see where there are used. So resources are used with functions like FindResourcesA etc… And as we can see, those functions are imported in the executable.
We have to see how the executable handle resource. Just to prove my point, here is the original JAR File size on the left and the file size of the Encrypted RCDATA resource on the right. So if you’re not familiar with Jar2Exe, know that the JAR File are stored in the Exectuable’s Resources since protection 2. So I decided to rework on it, and implement the protection 3 support.
It was a school project so I didn’t look that much to the protection 3, and someone shown me an issue about the output of my program regarding protection 3. I made a tool called Exe2Jar that unpack Jar2Exe protection 1 and 2. Today I will show how I unpacked Jar2Exe protection 3.