Hacking Java Bytecode for Programmers (Part 2)(acloudtree.com)
acloudtree.com
Hacking Java Bytecode for Programmers (Part 2)
http://www.acloudtree.com/lions-and-tiger-and-op-codes-oh-my-hacking-java-bytecode-for-programmers-part2
6 comments
Yeah, I'll clarify that bit. Basically I'm trying to convey.
- 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.
- 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.
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.
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
http://arhipov.blogspot.ie/2012/09/javazone-2012-taming-java...
this is good, about byteman, JRebel, tools like that
http://arhipov.blogspot.ie/2012/09/javazone-2012-taming-java...
>>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....
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....
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.
Rather than using a hex editor, one might consider a tool like Soot from McGill's Sable group. It includes a DSL for dealing with bytecode:
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.
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.
:) Agreed. ASM is awesome. I'm assuming we will get there.
I've never heard of soot. Thanks I've now starred it.
I've never heard of soot. Thanks I've now starred it.
What an annoying site to use on an iPad, can't pinch zoom
1. 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.