Hello all!

I was wondering if there is any tool that allows you to debug Java bytecode?

I know you'll probably say "decompile it". Well, when you've got
obfuscated Java code with a couple of thousand classes named stuff like acbv.class and ba.class with encrypted text string it's kinda time-consuming to find just the one that handles serial generation...

So is there any way to debug bytecodes or at least see which classes are loaded into the JVM? If not, whats YOUR usual approach when dealing with obfuscated Java apps?

Thanks!

Hi

I hate to say this but are any of the other java threads on this board of any use? Try a search for java and clandestiny and see if they help. good luck.

Kayaker

i still have yet to find a java debugger (other than softice, kayaker!), although i haven't really looked in about a year. i'd be interested to hear if you come across anything

oh, and btw, yes, i realize you can decompile a java target, and then use an ide to recompile and step through the source code, line-by-line with the ide's source debugger.

If you got crippled java code,
you should try to decompile it with
Bit-Arts JavaBite (I think it's spelled this way)
In the documentation they write that it can
handle crippled java code as well.

Try it out

I have to admit I am in a similar corner as crassy.

The obfuscated java code makes using a decompiled classes not very friendly. I have tried to locate the serial validation routines by using grep and finding the error messages with limited success.

There are some java debuggers. I d/l one called Jswat, which requires the bulky 80 Mb J2SDK from Sun microsystems.

At face value, it tells you that, in order to debug, one has to have compiled the classes with -d directive, so some debug info is available ( Theoretically, the same should be true with SoftIce). I have not have the time to tweek it aorund and see if it provides any helpful info that allows us to narrow down to the right serial validation code.

I hate to say this, but Kayaker showed us his incisive use of Sice to catch java loading classes. Could you, Kayaker, think of some way to use softIce to narrow down the class doing the serial validation? or generating the error message?

I think a possible solution would be in the lines of understanding the JAVA VM and placing BPX on the routines that generates message boxes, then try to extract out the name of the class that called the routine at the particular instance in which the "bad serial number" message box is generated.

I came across the beginnings of a java based bytecode debugger that used Apaches BCEL (Byte Code Engineering Library) to analyse compiled class files.

Haven't really tried it in anger yet (it's incredibly slow) but it appears to let you step through bytecode and set breakpoints. It's called JBCD.

the java classloader has a private store of loaded classes, i'm not sure how you can easily get that information out without subclassing ClassLoader. I seem to remember the java-plugin console letting you do it.

I've always ended up decompiling/deobfuscating by hand and then trying to work out what's going on

WeEeell..., if I knew dick-all about Java 2 years ago, I'm no better endowed in that category now than I was then. They say it's how you use it though right? ;p

The gist of it is that any MS Java app has to parse the class files through msjava.dll (or as someone mentioned in another thread, java.dll for Sun JVM), which of course makes it open to traditional debugging in Softice. If an encrypted class file(s) are used they must be decrypted with a loader class, but eventually also make it to java_lang_ClassLoader_defineClass() in msjava.dll as well.

At this point in the dll you have the filename and any decrypted code for each class file in the app as it executes. I'm not sure if you can change how a java app loads and executes, but at this api you can make a Class file dumper by inserting an inline patch to dump each decrypted class file to disk.

I think you're right naides, you could probably modify the code so you can "catch" which class file is being executed before the nag box comes up. Basically everything should stop there awaiting user input before the rest of the GUI comes up, unless the app protects itself in a more secure way. The patch could probably check for a new control Classname that indicated the nag window or something, (post-mortem by 1 class file). I had no problem cycling through the api manually until the nag came up, the correct buffer address and breakpoint displayed each class file name string as it was run.

For those too lazy to search..

http://www.woodmann.net/forum/showthread.php?threadid=1692&highlight=java+clandestiny

Kayaker

Thanks Kayaker & Co. I really didn't even consider SIce as a tool for working with Java. =) Now I know better. You've been a great help!

I have tried to make a bpx on i.e. _java_java_awt_button_initIds@8 (awt.dll from sun) to get information about the button in my java application. When I try to execute my program I get this error:

java.lang.UnsatisfiedLinkError: D:\j2sdk1.4.2\jre\bin\awt.dll: The process cannot access the file because it is being used by another process
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1477)
at java.lang.Runtime.loadLibrary0(Runtime.java:788)
at java.lang.System.loadLibrary(System.java:834)
at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
at java.awt.Component.<clinit>(Component.java:506)

How do I solve this problem? Thx


when I bpx on _java_java_lang_classloader_defineclass0@28 it's working (dump class files)