Implement second case in ZKM flow obfuscation

[iamkyaru]

I'm unsure if it would break with older or newer versions of ZKM and I can't test everything because I only had a single jar with ZKM flow obfuscation. Please fix if it breaks.

But I don't know if it's really intended to test the current instruction after a Jump Instruction using a Predicate and the previous one afterwards, although that should never be the case... right? That's why I fixed the check by using the current instruction node instead. I'm not sure if it depends on the ZKM version.

by the way: that case happen when booleans would be used instead of objects for the jumps.

[GraxCode]

I have never seen any file where boolean checks are used as control flow obfuscation by zkm, do you have a sample?

[GraxCode]

Also

        if (previous == null) {
          continue;
        }

is redundant, as it is already checked by the if before.

[iamkyaru]

Sorry, I meant it's sometimes an boolean or an integer which is getting compared with equality checks. Sometimes a boolean variable is created by calling a static method:

boolean b0 = I.c();

which then gets compared with IFEQ or IFNE instructions. And we know that booleans are loaded like integers. So the control flow would look something like this:

if (!b0) {
  break label1;
}
if (!b0) {
  break label1;
}

With integers it would be the same but I assume you know about that case?

[GraxCode]

I understand what you mean, but I have never seen it before being used by ZKM. Do you have a sample .jar file that shows that pattern?

[iamkyaru]

I have one, but I don't think if I would upload it here. Dou you have a Discord tag for me?

[GraxCode]

noverify#7184

[iamkyaru]

I sent you a request

[GraxCode]

Can you use the latest build to resolve merge conflicts? Source files were moved to gui/src/main.

[iamkyaru]

Done