3

I have a couple of classes that are encrypted. The class loader must decrypt these before executing in the JVM.

The question is, how and where?

What can I do to understand who is responsible to decrypt these classes before deploy?

Improve this question
2
  • Did you check whether it starts with the magic bytes CAFEBABE? If so, it's probably not encrypted. Commented Jan 12, 2016 at 14:42
  • Already checked it and also in hexview. I know class files structure so i am sure that is encrypted. Commented Jan 12, 2016 at 17:21

2 Answers 2

Reset to default
3

Find which of the visible classes implement java.lang.ClassLoader.

Then you can look at its findClass and findResource implementation.

Improve this answer
2
  • I can't find the key that i need to unencrypt classes. I forget to mention that i have a lancher.exe that initialize the jvm, most probably will be there. Did you have some suggestion to find the key from there without reverse engineering all calls to jvm in Ida? Commented Jan 12, 2016 at 17:23
  • 1
    You'll need to intercept the call that sets the key for decryption. Stepping through with a debugger until it enters the decryption routine should help. Commented Jan 12, 2016 at 17:26
0

I also had this issue, where I was trying to decompile some java classes but they were all encrypted and I think there is a non obvious solution I would like to mention before I describe how to actually do the decrypting and that is:

(1) Try and find an older version of the software that doesn't contain encrypted classes. If it is a public application you might be able to find older version on archive.org and it's very possible that the classes were not encrypted in the older version.

However, if you are stuck with an encrypted jar, or java application loaded from a native application then there is a pretty obvious way to decrypt it, and the principle of how to do this are described in this infoworld article. But these are just the principles, how do you do this in practice?

Well the most obvious way that I found is to dump the classes loaded by the jvm. The article describes making edits to .class files that pretty much do exactly this, but it's kinda hard to do this if your class files are loaded by a .exe or something. Whether you're trying to decrypt a java class that is loaded by a .exe/.dmg/.jar it will have to at some point touch a jvm - I think. Knowing this, we can use an external tool to do the dumping instead of editing the java program to dump its own files.

At a high level the way to do this is:

  1. Download dumpclass.jar- this is the external tool that can look in the jvm and dump the classes we care about.

  2. Setup dumpclass.jar - This step is a bit annoying because dumpclass.jar needs to run on the same jvm that is running your encrypted java classes. What makes it harder is that dumpclass.jar depends on some parts of the jdk which, if your application is using a .exe to launch itself, it can be pretty hard to use a specific jvm, like the one from the jdk, to launch it. Also it can be difficult if your java application will only run on an older version of the jvm, which doesn't support dumpclass.jar, or will only think java is installed if it finds a /jre/ folder on your computer, despite what you set the JVM_HOME environmental variable to. This step is actually a lot annoying and it's hard to give a step by step description because it depends a lot on what you're trying to reverse engineer. However, assuming your java application can run on a jvm that is higher than 1.6, because before that one of the dependencies of dumpclass works in a weird way, then ideally you will: (1a) install the jdk(!) of your choice. (1b) Run your java application with the jvm in the jdk...

  3. Run dumpclass.jar with the jvm in the jdk and make sure it can display a usage message

  4. Then you can get the process of the java application with the java classes you want to decrypt, if this is an exe you will use the exe process id.

  5. Run the dumpclass.jar command, on the process id, with a small modification. The original command asks you to give a filter so that you don't get every class on the jvm. However, I think it is much simpler to just get every class in the jvm and the browse to the one you are looking for in once they have been dumped. Specifically, while the dumpclass docs say you should do this java -jar dumpclass.jar -p 4345 *StringUtils rather do this java -jar dumpclass.jar -p 4345 - the files should all be dumped right next to the location of the dumpclass jar. And then you can browse through them to find the decrypted .class files of the application you care about.

NB: If dumpclass says 0 classes dumped after you run it, but takes a while to do the dumping, ignore it, the classes were dumped and for some reason it is not reporting the correct number of classes. If you don't see the classes next to dumpclass.jar try setting the output path explicitly.

Some other tips:

  • If you run into an error that talks about SwDbgSrv see my answer here: https://stackoverflow.com/questions/10783256/how-to-start-swdbgsrv-exe-in-windows-7/64321750#64321750
  • Use bytecode-viewer to decompile the classes once you have decrypted them, it's really good
  • If you run into other errors about missing java libraries then its possible that dumpclass is not using the jdk jvm, in which case you will either have to make sure it is, or copy the libraries from jdk jvm to the jre jvm. For example this happened to me with the sa-jdi.jar, it was included with the jdk but because I was using the jre jvm, because the application I was trying to decompile couldn't find the jdk, I ran into tons of errors. I eventually tried to download the .jar just from a google search and that caused even more errors. If this happens to you, you will pretty much just need to download the jdk for your jre version and copy the specific libraries it can't find from the jdk to the jre. There are only a few.
Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.