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

by jfolkins • 13 years ago

48 12 13 years ago

maxbaroi2• 13 years ago

I'm not being facetious. I don't know anything about the implementation of the JVM or its byte-code, and was hoping to learn a bit. But...

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.

jfolkins4• 13 years ago

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.

maxbaroi2• 13 years ago

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.

coin• 13 years ago

What an annoying site to use on an iPad, can't pinch zoom

cypher543• 13 years ago

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.

gtani• 13 years ago

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...

jfolkins4• 13 years ago

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.

voidlogic• 13 years ago

>>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....

ShabbyDoo• 13 years ago

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.

jfolkins4• 13 years ago

:) Agreed. ASM is awesome. I'm assuming we will get there.

I've never heard of soot. Thanks I've now starred it.

mbell• 13 years ago

Minor nit pick:

"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.

jfolkins4• 13 years ago

Corrected! Thanks!

Hacking Java Bytecode for Programmers (Part 2)

Related Stories