intercept calls to javax.crypto

Question

There is a certain obfuscated java application I want to check out. The code is poorly obfuscated but it's enough to have difficulty following the execution flow. Since I am only interested in seeing what kind of data it's trying to send, I also think it's a bit overkill trying to completely reverse engineer the application.

I fired up wireshark to debug traffic and it connects to a server, gets a blob of binary, seems to do some handshaking and then do some query's completly encrypted. By inspecting the decompiled code I know he's using rsa, blowfish and "sha1andrsa" signatures to sign some things. This leads me to believe that it's using rsa with a key it get's from the server (the blob of binary) to exchange blowfish keys and proceed from there. This makes it virtually impossible to inspect traffic by mere sniffing.

I'd like to do the java analogy of a proxy dll, I want to intercept all calls to javax.crypto.cipher and see what kind of data it tries to encrypt with what keys. I'd also like to deliver my own blowfish key so I can read traffic (with the assumtion that all traffic after handshaking is only blowfish encrypted).

I can't simply recompile javax.crypto.cipher as this isn't delivered in src.zip with the jdk. I haven't found that much documentation on what I'm trying to do leading me to believe that this isn't the right/best way to go about this. Is there alternatively some kind of dynamic java debugger capable of intercepting those calls?

edit: I went on arch, downloaded openjdk, extracted and modified the needed files, recompiled and placed them in a directory modded. Then I added -Xbootclasspath/p:./modded -verbose:class to the argument and I notice that my modified class is not getting loaded from /modded but instead from the standard library. Is this a bug?

Answer 1

So, based on the helpful comments I managed to figure it out.

The src.zip given by the jdk is incomplete, if it doesn't contain the class you need to modify, try going with openjdk.

While the best practice would be to use -Xbootclasspath with a directory with your modified files, it simply does not work (or is too cryptic to figure out). There is however, jce.jar which contains javax.crypto somewhere in a hidden jre/lib directory. You should unzip the jar, replace the compiled class files and rezip everything. This finally works :D