AppletTalk.com

Pat LaVarre · Guest

Just now I saw someone offline near here ...

.... hoping that substituting an assembler for javac could make .class
files harder to decompile & recompile.

Anybody here know how vain that hope is or is not?

I hear some people do write systems for disassembly & reassembly that
choke over creative assembly code. I imagine more choke in the
reassembly stage than in the disassembly stage, but I imagine some,
possibly many, choke back in the disassembly stage too.

Some disassemblers - my pjb in particular - by design pass thru fully
arbitrary input. If any version of pjb chokes over any input, then
that version has a bug, which hopefully we (the net) will find and
fix. I suppose the net already has experience with fully arbitrary
disassembly of x86 machine code?

As our most massively distributed example, we have the `javap -c`
disassembler of Sun's JDK. That disassembler leaves out supposedly
inessential details like the order of entries in the constant pool.
That disassembler ships without an accompanying reassembler. I wonder
if in fact `javap -c` can disassemble any .class file that the
accompanying `java` can interpret.

I do know by policy now I ship .jar's containing both .class and .java
because once upon a time I lost the .java for an app of mine. All I
had left was a .jar of .class. Via `javap -c` I disassembled the
..class files, I translated back to .java by hand, and I rebuilt my
working app.

If indeed `javap -c` can disassemble what `java` can interpret, then a
cheap manual attack like that will rebuild any app, no matter if
assembled or compiled originally.

"Security by obscurity by definition is weak, and dissolves into
nothing when it meets an expert, though admittedly even security by
obscurity is not as weak as zero security. In particular, security by
obscurity enters into the equation that security times usability is a
constant."

Pat LaVarre