Trying to decompile a Class that has 2 inner classes (xxx$1.class and xxx$2.class)

[ohaya]

Hi,

I am trying to decompile a class that has 2 inner class files:

xxx.class xxx$1.class xxx$2.class

I am trying to do this so that I can modify the code (using Eclipse) to add additional debug output.

How should I do the decompile? Do I decompile each of the files individually, one at at time?

Thanks!

Jim

[Col-E]

You would do only the xxx.class while also making sure that CFR has access to the inner classes xxx$n.class so that it can include them in the decompiled output.

tree /f

example-dir/

• cfr.jar
• foo$bar.class
• foo.class

java -jar cfr.jar foo

class foo {
    bar bar = new bar();

    foo() {  }

    class bar {
        bar() { }
    }
}

As long as the directory structure matches the class, CFR will find and include the inner class. Also, if they are the only classes in the jar file, you can feed CFR the jar and it will only decompile the top level classes.

[ohaya]

Hi,

Thanks.

The class I am trying to decompile is one of the Java classes (I mean it is part of Java). Specifically it's a class inside jsse.jar that I am trying to add more debug to try to figure a problem we're having.

So the class is in package sun.security.ssl, e.g., the class itself is sun.security.ssl.XXX.class and there are two inner class files, sun.security.ssl.XXX$1.class and sun.security.ssl.XXX$2.class.

So following what you said should they just be:

• cfr.jar
• XXX$1.class
• XXX$2.class
• XXX.class

??

Or do they need to follow the package/directory structure?

• cfr.jar
• XXX.class ---- sun/security/XXX$1.class ---- sun/security/XXX$2.class

??

Thanks, Jim

[Col-E]

My example didn't specify a package name, but you will want to match the package names with your directory structure.

[leibnitz27]

You dont need to match package structure if you're analysing an individual class and inner classes - CFR will "reroot" the class in whatever directory you loaded it from, and will attempt to load classes from the same package from that same directory, if possible.

[leibnitz27]

Note also - you may not actually see (what appear to be) inner classes by name in a decompilation - they can be used as tokens to control access, or they may be anonymous inner classes (eg sun.security.krb5.Config$1 is an anonymous inner used in the loadConfigFile method - in jre8 at least)

[Marcono1234]

The class I am trying to decompile is one of the Java classes (I mean it is part of Java). Specifically it's a class inside jsse.jar that I am trying to add more debug to try to figure a problem we're having.

Have you had a look already at the OpenJDK repository (respectively the update repositories such as jdk11u-dev)? I would assume that it contains the source code for the class in question. Keep in mind that deploying a modified JVM is illegal, see also this StackOverflow question. In case you are not aware of it, there are also options for getting debug output for TLS / SSL connections, see "Debugging SSL/TLS Connections" and "Troubleshooting JSSE". Otherwise, is Remote Debugging not an option for you? This might be simpler than having to modify JDK classes.