Are these encoded codes?

Question

hi, i used a decompiler to decompile a .class file it seems that it decompiled everything except some code at the bottom are very strange and since im new to java im not sure what they mean:

  static
  {
    String[] tmp5_2 = new String[6];
    jsr 50;
    tmp5_2[0] = "pH@JeAE";
    String[] tmp13_5 = tmp5_2;
    jsr 42;
    tmp13_5[1] = "lRMMoF";
    String[] tmp21_13 = tmp13_5;
    jsr 34;
    tmp21_13[2] = "KHUT;\f\19VSv\rRHJkBJH@dL\18OAu";
    String[] tmp29_21 = tmp21_13;
    jsr 26;
    tmp29_21[3] = "\18\14\22\n1\r\f\15\21";
    String[] tmp37_29 = tmp29_21;
    jsr 18;
    tmp37_29[4] = "wTD\4OJRKEWJXDK@SLMAu\3UR\4NMPHJd\r";
    String[] tmp45_37 = tmp37_29;
    jsr 10;
    tmp45_37[5] = "KHUT;\f\19\16\226\r\f\15\20/\18\19RP`WIR";
    z = tmp45_37;
    break label68:
    label68: localObject = returnAddress;
  }

see the code after tmp5_2[0] for example, what do they mean?

Answer 1

These are most likely encrypted strings for use within the application. The applet should include some sort of decryption routine for them or it wouldn't be able to use them. This looks to me like a poorly decompiled or obfuscated initialization code for some field in the class called z (an array of String).

As far as Java is concerned, these are just regular string constants. There is no special significance to them whatsoever.

Answer 2

Judging from a quick glance, and I could be totally wrong, it looks like code that has been obfuscated by an obfuscation tool as to prevent what you are trying to do (reverse engineering)

Answer 3

Note that the code you post is not valid Java code.

The bytecode you de-compiled to get this was most likely obfuscated by some obfuscator that also obfuscates String constants (the only obfuscater I use occasionally is ZKM and that does something similar).

Note this code in your sample:

jsr 50;

That's not a valid Java statement and is included by the decompiler to tell you that there was a bytecode instruction that it couldn't de-compile into a valid Java source statement.

jsr is effectively a gosub (i.e. it pushes the return address on the stack and invokes the bytecode at the specified offset, it's usually used to implement finally-blocks), so this code is probably used to jump to some String "decryption" subroutine (I put decryption in quotes because it most likely isn't a strongly typographic decryption at work here).