Depending on the class loading order, moving them can result in arrays
being empty, which breaks the client's functionality (e.g. it can't get
past the JS5 CRC check).
The client scrambles static fields and methods - moving each to a
random class where it does not logically belong.
This transformer moves all static methods to a new set of empty classes.
The intention is that the human refactoring the deobfuscated client can
move the static methods around with an IDE to classes where it makes
sense.
In theory we could use heuristics to move some methods around - e.g.
ideas I have include:
* If the method takes no arguments, move it to the same class as its
return type.
* If it's a void method that takes one argument, move it to the same
class as its single argument.
* Group related methods together based on where they are called.
However, some of the heuristics are probably fairly complicated to
implement. Furthermore, as they are heuristics, they will make mistakes.
In the naive approach, the Static* classes generated by this transformer
effectively act as a queue of methods that a human has yet to move to an
appropriate class. If the Static* classes are ever emptied after
refactoring, then we will know that all static methods have been moved
to an appropriate class.
We wouldn't be able to guarantee this if some methods were moved to
Class* classes with heuristics. The heuristics would also be fairly
complicated to implement. Therefore, the transformer does not use
heuristics.
Field scrambling support will be included in a future commit.
Graham