![]() |
|
|
|
#1
|
|||
|
|||
|
I used to use ObjectWebs ASM (http://asm.ow2.org/) to disassemble Java bytecodes to Java code. Then modify that Java code, re-compile it, and use it to generate a proper bytecode file. It's a little bit round about but it works wonderfully and more versatile than patching alone.
|
| The Following User Gave Reputation+1 to For This Useful Post: | ||
besoeso (04-12-2012) | ||
|
#2
|
|||
|
|||
|
Hi
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. |
| The Following User Says Thank You to Mkz For This Useful Post: | ||
Indigo (07-19-2019) | ||
|
#3
|
|||
|
|||
|
There is rather a new tool, very similar to JBE (JBE is obsolete as it won't "patch" all .class files reliably when select features of java 1.6 are used) it's called DirtyJOE. In my opinion, its the easiest way/tool to reverse java. DirtyJOE has an Opcode library that will let you know what that particular java opcode or "bytecode instruction" signifies... http://dirty-joe.com/
I'm also happy to help... clarify and instruction or if you are simply looking for a way to do something... As a decompiler, I recommend using DJ as it is very quick and simple... http://java.decompiler.free.fr/?q=jdgui the basics to reverse java are... 1.Serch for the code to be patched with DJ; 2.Use winRAR and extract the .class file containing the "magic" section of code; 3.Get cracking with dirtyJOE. For JNLP applications, you need first to dig out the relevant .jar files... they are all in the java cache folder... marrom |
| The Following User Says Thank You to marrom79 For This Useful Post: | ||
Indigo (07-19-2019) | ||
|
#4
|
|||
|
|||
|
Password sniffing in Java
This is just an idea, I don't actually know much about Java but I do understand that Java code runs in a virtual machine (JVM) which is essentially a set of DLLs on windows, so shouldn't there be a way to set breakpoints directly in these DLLs while the virtual machine is interpreting and running a jar?
This could be useful for sniffing serials and the like for example... |
| The Following User Says Thank You to wassim_ For This Useful Post: | ||
Indigo (07-19-2019) | ||
|
#5
|
||||
|
||||
|
Dr. Garbage Tools is a suite of Eclipse Plugins released under Apache Open Source license. Before is comercial.
-Bytecode Visualizer
-Sourcecode Visualizer
http://www.drgarbage.com/index.html |
| The Following 2 Users Gave Reputation+1 to besoeso For This Useful Post: | ||
chessgod101 (07-03-2012), Shub-Nigurrath (07-03-2012) | ||
|
#6
|
|||
|
|||
|
JBE is really a good program.
But as far as I can see it, you can not directly change the opcodes in the program. Should I fool myself, let me know. |
| The Following User Says Thank You to CRC32 For This Useful Post: | ||
Indigo (07-19-2019) | ||
|
#7
|
|||
|
|||
|
JBE or JEB? I have studied how to reverse apk for 20 days.I know a tool named JEB(a interactive android decompiler) also powerful.Are we talking about the same thing��If someone knows, tell me please. Thank you��
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| java self-contained application packaging cracking | Chuck954 | General Discussion | 3 | 08-20-2022 00:57 |
| Java Cracking... | deephousederek | General Discussion | 5 | 05-17-2005 07:55 |