Visualize hex-to-bytecode mapping

[Col-E]

Feature

Allow users to see a display similar to this:

Ideally for the entire class file, rather than just the method bytecode. But the method code would be good for now and could be expanded later. This is handy for things such as writing YARA rules where knowing the hex is necessary.

Process

This will likely be implemented using CAFEDOOD once it is fleshed out more, specifically once this issue is completed: Col-E/CAFED00D#1

[lillypad]

This would be a great feature!

[Col-E]

Some thoughts on this, if its ok that the index pointers are not included then just showing the bytecode of instructions' opcodes + argument wildcards could be done. The reason the indices would not be included is because ASM handles rewriting the constant pool, so we don't really know where the things will point to until we save the entire class. And even then ASM doesn't tell us what points where in the constant pool since it abstracts things away. We'd have to use another lower abstraction bytecode library for that.

Anyways, an example of what just showing hex for opcode patterns would look like:

START:
 ALOAD this
 INVOKEVIRTUAL com/example/MyApp.doLog()Z
 IFEQ END
LOGGING:
 GETSTATIC com/example/MyApp.logger Lorg/slf4j/api/Logger;
 LDC "Logging message"
 INVOKEVIRTUAL org/slf4j/api/Logger.info(Ljava/lang/String;)V
END:
 RETURN

Would show up as (comments included for clarity):

// start
2A     // aload_0
B6 ??  // invokevirtual <method-ref>
99 ??  // ifeq <branch-offset>
// logging
B2 ??  // getstatic <field-ref>
12 ??  // ldc <cp-utf8-index>
B6 ??  // invokevirtual <method-ref>
// end
B1     // return

Could probably expose some UI bits so you can make a plugin that lets you select the lines you want and export the hex pattern to your clipboard.

[Col-E]

Working on a new hex editor in 3X

D2hbhKXXdA.mp4

The plan is to make it so you can correlate regions of the class file to the displayed hex. This will still require a bit of extra work, but the design now fully accommodates for this use case :)

The next step is to flesh out CAFED00D so that it will optionally let you get back the hex offsets from the data representation. My rough idea for this is to make it so that there is a common class representation over interfaces, but implementations can be provided via an optional factory. One could implement a factory that tacks on the offset information to data that gets parsed.

[Col-E]

Scrapped the factory idea in CAFED00D. Instead we're going to just locally map ranges based on expected specification sizes with the existing CAFED00D ClassFile type.

Here's a half-baked preview of what it looks like so far:

Only limitation for what can be expanded is:

• What is implemented as parsable in CAFED00D
• What I bother to implement UI cases for in the tree cell in Recaf 3x

But once CAFED00D is fleshed out (Which is just honestly busy-work reading the specs) it'll even be able to map method instructions to the hex directly. I also plan on having regions color coded in some fashion. I don't have a plan on how its supposed to look yet. Some things to consider:

• Difference between items at the top level of the tree
• Difference between sub-items of a top-level item (and so on, down the tree depth)