Thread: java cracking
View Single Post
Old 04-18-2012, 03:04
Mkz Mkz is offline
Join Date: Jan 2002
Posts: 98
Rept. Given: 0
Rept. Rcvd 2 Times in 2 Posts
Thanks Given: 5
Thanks Rcvd at 25 Times in 17 Posts
Mkz Reputation: 2

Just though I might add my own tip for cracking java.
Notice: I know how to program in java (I also know the bytecode of course), and at least some basics are needed even if just for patching an instruction - objects, stack, etc.

Well, since I don't usually run under a debugger (IDA or higher-level), what I do sometimes is have a static look at the code - normally with JD - and find interesting spots. Examples: encrypted strings, strange file accesses, etc. Just by the nature of the java.*.* objects being used, you often get a pretty good idea of what's going on, and those can never be obfuscated like the programmer's code.
Then you need to patch the framework's code itself. "String", for instance, is a class you can easily change. Just fetch the java rt sources (it comes with the sdk), copy it to your own version, and for instance in the constructor just do a "System.out.println(this);".
Want the stacktrace as well to know where this string was created? Just add another statement with "new Exception().printStackTrace();"

The only thing left is to make java use your version of the rt classes instead of the original ones. Just add this modifier to the invocation:
java ... -Xbootclasspath/p:my_path\my_jar_with_changed_stuff.jar ...
There you go. All constructed strings (a LOT) will be written to the console, followed by the stack trace of the place they were created.

Extending this technique, I once also did something with the java.lang.Exception class. Changed the source so that every single exception wrote the stack trace to a log (be it the captured ones, the ones that happen during regular class loading, etc.) - creates a huge log but also allows you to know about everything that got raised and might not be even been propagated to error windows or log files.
Since the output is so huge, I later added some logic to it: created a settings file that could be supplied in the command line and where one could create regular expressions for the stack traces to ignore in order to hide "normal" exceptions that are raised a lot.
Unfortunately, this was quite some time ago and I no longer have the code at hand. Still it's not hard for someone to do it if needed.
Reply With Quote
The Following User Says Thank You to Mkz For This Useful Post:
Indigo (07-19-2019)