WIP: Zelix String Transformer V2 (because of new pattern)

[toidicakhia]

Concept: This transformer copies methods and fields that related to decryption to a temp class. This concept prevents invoking other class's method, cause a lot of errors.

It can be solved on issue #5

TODO:

• Fix SSVM issue when executing toCharArray() (PR Make SSVM use java 8 runtime classes #112)
• Clean temporary classes
• Better detect long keys (by @d-o-g)
• Better decrypted clinit detection
• Better detect encrypted string array
• Clean encrypted function and static
• (III)Ljava/lang/String decryption
• Local array decryption
• Inline local array

[toidicakhia]

@EpicPlayerA10 can you test SSVM with calculating bitwise operator? I have some issues with transformer.

[toidicakhia]

Confirmed that SSVM is broken on Java 17 (when executing toCharArray())

[EpicPlayerA10]

Confirmed that SSVM is broken on Java 17 (when executing toCharArray())

I had also an idea to provide to SSVM all classes from java 8 binary, so it could run on any java version.

[EpicPlayerA10]

@toidicakhia Could you test this PR #112 ? This PR implements my idea about providing classes from java 8 rt.jar. This should fix your issues with SSVM.

[EpicPlayerA10]

You can also add your ZelixStringTransformer to the ComposedZelixTransformer to also apply this transformer to other zkm test samples.

[toidicakhia]

This PR will not be merged until I fixed an issue.

[toidicakhia]

Now we have new issue, new decryption method (III)Ljava/lang/String;

[d-o-g]

@toidicakhia there is a specific instance where it fails to identify the decryption stack.

         sipush -3214
         L0 {
             aload 0 // reference to self
             invokevirtual Class_11.getClass_13_6()LClass_13;
             astore 1
             sipush -31934
         }
         L1 {
             invokestatic Class_11.a(II)Ljava/lang/String;
             ....
         }

  private static final Match DECRYPTION_MATCH = SequenceMatch.of(
      NumberMatch.numInteger().capture("key1"),
      NumberMatch.numInteger().capture("key2"),
      MethodMatch.create().desc("(II)Ljava/lang/String;").capture("method-node")
  );

SequenceMatch will not always be reliable as ZKM sometimes defines their control fields in the middle of invoke stacks.

This is how I fixed it:
https://paste.strictfp.com/cutewijayo.java
private static final Match DECRYPTION_MATCH = new ZKMDecryptArgsMatch();

[d-o-g]

There also appears to be instances where instead of 2x static final String[], the class only has 1 single static String field. The transform often fails on these.

And 1 more instance where the strings are pulled from the local array in rather than the field:
example:

var0 = new String[2];
...
X = new ResourceLocation(var0[0], var0[1]);

[toidicakhia]

There also appears to be instances where instead of 2x static final String[], the class only has 1 single static String field. The transform often fails on these.

And 1 more instance where the strings are pulled from the local array in rather than the field: example:

var0 = new String[2];
...
X = new ResourceLocation(var0[0], var0[1]);

Fixed

[toidicakhia]

You can also add your ZelixStringTransformer to the ComposedZelixTransformer to also apply this transformer to other zkm test samples.

Updating recompiled classes is essential, since ZelixLongEncryptionMPCTransformer can modify results before running this transformer.