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?
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:
Download dumpclass.jar- this is the external tool that can look in the jvm and dump the classes we care about.
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...
Run dumpclass.jar with the jvm in the jdk and make sure it can display a usage message
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.
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:
SwDbgSrv see my answer here: https://stackoverflow.com/questions/10783256/how-to-start-swdbgsrv-exe-in-windows-7/64321750#64321750