Unfortunately we can't use the compiler to guarantee k isn't changed,
though making it internal will help. When the JVM (and Kotlin) get value
types, we might be able to improve on this (e.g. by making it an inline
class of four integers).
Signed-off-by: Graham <gpe@openrs2.dev>
This commit improves support for simplifying a series of multiple
additions/subtractions and doing so in a single pass.
Signed-off-by: Graham <gpe@openrs2.dev>
This commit makes two changes:
* Uses the is operator instead of the isXXX methods provided by
JavaParser, allowing smart casts to be used.
* Wraps unsupported expressions with a unary minus expression, rather
than throwing an exception.
Signed-off-by: Graham <gpe@openrs2.dev>
This commit updates the tests to ensure all combinations of 0-7 bytes of
leading/trailing blocks of unencrypted bytes work correctly with all
test vectors.
Signed-off-by: Graham <gpe@openrs2.dev>
We could use LocalVariableTable in theory, but it's more complicated as
we'd need to do live variable analysis and type inference. It's much
easier to leave that for the decompiler.
Signed-off-by: Graham <gpe@openrs2.dev>
The next commit will introduce an ArgRef class which uses a MemberRef
directly, rather than a MemberRef partition.
Signed-off-by: Graham <gpe@openrs2.dev>
This allows two different classes in different modules to be refactored
to the same name - for example, Node in client and unpackclass.
Under the hood, it is implemented by prefixing each class name with the
library name and an exclamation mark (which is highly unlikely to appear
in a class name, as it is invalid Java syntax).
At first, prefixing class names with the library name feels like a bit
of a hack. However, it is much simpler than trying to track libraries
throughout the existing code. Furthermore, it allows us to avoid
forking ASM classes like Remapper.
The Fernflower driver was also changed to deobfuscate each library in
its own context, rather than trying to decompile them all in one go - by
the time classes reach Fernflower, the prefixes have already been
removed and Fernflower can't deal with duplicate class names either.
Signed-off-by: Graham <gpe@openrs2.dev>
I think it is better to be explicit here, instead of relying on ASM's
current lack of equals()/hashCode() methods in the AbstractInsnNode
class.
Signed-off-by: Graham <gpe@openrs2.dev>
I suspect it is excluded on Jagex's end so the client deals correctly
with any class loading failures caused by the absence of the
netscape.javascript.JSObject class.
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>
JS5 seems to refer to many things, so I'm intending to name Jagex's
custom class file format "packclass" instead of "js5". My reasoning is
that the tool for unpacking it is called unpackclass. If you use the
same logic behind naming the Pack200 packer unpack200, then "packclass"
is a reasonable name for Jagex's class file format.
Signed-off-by: Graham <gpe@openrs2.dev>
