Thanks for the reply. Look forward to the next post. I guess I prefer to be bogged down, or at least have the ability to go deeper off some tangent and then be able to return to the main lesson.
Maybe I'm not part of the target audience for this article, but it seems to lack quite a bit of information. For example, you explain what op-codes are, but then only cover one of them. I think at least a basic overview of common op-codes and how they work together would have been great. Also, the "hacking" you demonstrate is simply replacing a string, which is certainly not Java-specific and rarely useful. A more interesting example would have been changing the control flow in some way.
Of course, that's not to say it's a bad article. I just think you could have expanded quite a bit more.
I think target audience is folks who're mucking around the low-levels using javap, proguard, Jconsole/visualVM tools (jmap, jstack etc) and other diagnostic/disassembler tools like that for benchmarking/tuning, picking hotspot command line options, looking for malware, shoehorning into android etc. Javap is pretty well documented, you could start there.
this is good, about byteman, JRebel, tools like that
Nah, I think you probably are. I'm just laying the ground work so that someone could start at the beginning and get to the point where they can, say, change a if_icmpeq to a if_icmpne.
>>Maybe I'm not part of the target audience for this article, but it seems to lack quite a bit of information.
I think for anyone with minimal assembly experience or a desire to learn this is pretty straight forward.
>>For example, you explain what op-codes are, but then only cover one of them.
He gives you a link to the list of all of the op codes... Did you read it?
>>I think at least a basic overview of common op-codes and how they work together would have been great
Maybe this is going to be in a follow up article. But after explaining the concept, giving you toy example and giving you the opcode list, with the provided hexdump you should be able to start doing this yourself. Try it! Its fun.
>>Also, the "hacking" you demonstrate is simply replacing a string, which is certainly not Java-specific and rarely useful
Intro to concept examples are often toy examples....
Every time I see a Java article I think to myself how Java is so far behind C#. I feel like MS took all of the things that make Java great and made it way better and all of the Java fan boys either can't comprehend that or choose not to.
I also don't like how it has a silly name and everything around it has names synonymous with Coffee.
It includes a Java source generator which, given a .class file as input, produces a Java source class which will regenerate the input via the ASM builder APIs. Obviously, the benefit is that you get a starting point for building various re-writers, analyzes, etc.
13 comments
[ 5.1 ms ] story [ 37.7 ms ] thread1. How was I supposed to know 0x19 was the relevant byte to look at? I know there should be a load opcode somewhere, how do I know it was that 0x19?
2. What's going on between the load opcode, and the actual string data about 120 bytes apart?
3. Is looking up the definition of an opcode from a list really a mnemonic device?
Maybe that last bit was a bit facetious.
- Opcodes exist - Here is one of many - Don't squish them
Edit: I also should mention that my style is a show/do. I'm trying to balance how much to tell the reader, but not bog them down.
In my next post we can take a look at the disassembler javap and dive in a bit more.
Of course, that's not to say it's a bad article. I just think you could have expanded quite a bit more.
this is good, about byteman, JRebel, tools like that
http://arhipov.blogspot.ie/2012/09/javazone-2012-taming-java...
I think for anyone with minimal assembly experience or a desire to learn this is pretty straight forward.
>>For example, you explain what op-codes are, but then only cover one of them.
He gives you a link to the list of all of the op codes... Did you read it?
>>I think at least a basic overview of common op-codes and how they work together would have been great
Maybe this is going to be in a follow up article. But after explaining the concept, giving you toy example and giving you the opcode list, with the provided hexdump you should be able to start doing this yourself. Try it! Its fun.
>>Also, the "hacking" you demonstrate is simply replacing a string, which is certainly not Java-specific and rarely useful
Intro to concept examples are often toy examples....
I also don't like how it has a silly name and everything around it has names synonymous with Coffee.
https://github.com/Sable/soot
I had looked at Soot some time ago because of Dava, the Java decompiler included with the project.
Also, for programatic manipulation of bytecode, ASM is a great tool:
http://asm.ow2.org/
It includes a Java source generator which, given a .class file as input, produces a Java source class which will regenerate the input via the ASM builder APIs. Obviously, the benefit is that you get a starting point for building various re-writers, analyzes, etc.
I've never heard of soot. Thanks I've now starred it.
"The second, and this probably goes without saying, is that data is actually stored in the compilation using hexadecimal. "
It's stored in binary, your just using an editor that displays the hexadecimal representation.