This already caught some cases of public members that should have been
private and one case where the inferred type was too specific.
Signed-off-by: Graham <gpe@openrs2.dev>
This will make naming libraries easier, as we won't have to thread
library names through every Library{Reader,Writer} implementation.
Signed-off-by: Graham <gpe@openrs2.dev>
This change paves the way to feed the NameMap into the TypedRemapper,
such that refactored names (and static member movements) are preserved
across deobfuscator runs.
Signed-off-by: Graham <gpe@openrs2.dev>
Java 11's Pack200 implementation complains if stack map frames are present, and
passes the classes through unmodified. I'm not sure why.
Stack map frames are only required in Java 7, so for 6 and below a reasonable
workaround is to not emit them.
A nice side effect of this change is that the jar files created by the bundler
are be smaller. The pack200 files are too, and would be even if the classes
were not passed through unmodified.
As I'm splitting it up into smaller modules (e.g. compress and crypto) I
think util is a more appropriate name for the remainder.
Signed-off-by: Graham <gpe@openrs2.dev>
This allows us to avoid needing to worry about manipulating stack frames
in individual transformers, which adds lots of complexity. It's much
easier to just make ASM generate them for us.
Signed-off-by: Graham <gpe@openrs2.dev>
This is necessary for a future commit that will track the original
indexes of AbstractInsnNodes throughout the deobfuscator, with the aim
of using this information to track local variables in the decompiled
code.
I suspect this will also improve performance, as we don't need to
re-allocate all of the tree objects.
This isn't ideal as it's deprecated. However, while Apache Harmony's
unpack200 implementation seems fine, its pack200 implementation doesn't
work with the client and produces invalid output.
I've fixed some of the easy to fix bugs, but tracking down any remaining
bugs will be difficult - it'll involve tracing through the native
unpack200 code.
When Pack200 is removed from the JDK, hopefully someone will take up the
mantle of maintaining it outside of the JDK. If that doesn't happen,
we'll have to consider writing our own Pack200 implementation,
extracting OpenJDK's implementation out of the tree or fixing the bugs
in Apache Harmony.
