CFR is a modern CLI Java Decompiler, you can download it at http://www.benf.org/other/cfr/

If you're looking for GUI CFR, check out Bytecode Viewer - https://github.com/Konloch/bytecode-viewer/releases

To run it, simply use:

Code:

java -jar cfr.jar input.jar --outputdir ./output/

does this deobfuscate too?

does this deobfuscate too?

I'm not sure, I know FernFlower has the -ren option.

does this deobfuscate too?

Depends what you mean - it has multiple normalisation passes to deal with lots of interesting potential obfuscations, it doesn't trust most of the metadata attributes (signature table, variable name table etc.).  The normalisation passes quite often have a very good effect against obfuscated code, though there's always the classic illegal java rewrites (like replacing a loop with a self-vectoring exception table).

It will however currently not rewrite method names if they've been obfuscated into non-java compatible identifiers - this is because at that point, there's a danger that reflection based invokation will change semantics.

Lee.

(BTW - I wrote it )

classic illegal java rewrites (like replacing a loop with a self-vectoring exception table).

what u mean

classic illegal java rewrites (like replacing a loop with a self-vectoring exception table).

what u mean

what u mean

classic illegal java rewrites (like replacing a loop with a self-vectoring exception table).

what u mean

what u mean

This.

Take a loop, remove the back jump, replace it with a catch handler at the top.  That one's fairly easy to handle.  Then, wrap the body of the loop in a boolean so it only gets executed every other time via a forward jumping exception handler.

Here's an example:

Code:

 public static void main(java.lang.String[]);
   Code:
      0: new           #16                 // class java/lang/Exception
      3: dup          
      4: invokespecial #14                 // Method java/lang/Exception."<init>":()V
      7: astore        4
      9: getstatic     #17                 // Field java/lang/System.out:Ljava/io/PrintStream;
     12: astore_1      
     13: ldc           #11                 // int 10
     15: istore_2      
     16: iconst_0      
     17: istore_3      
     18: aconst_null  
     19: pop          
     20: iload_3      
     21: ifne          27
     24: aload         4
     26: athrow        
     27: aload_1      
     28: iload_2      
     29: dup_x1        
     30: invokevirtual #24                 // Method java/io/PrintStream.print:(I)V
     33: ifne          37
     36: return        
     37: aconst_null  
     38: pop          
     39: iconst_1      
     40: iload_3      
     41: dup          
     42: ifne          51
     45: iinc_w        2, -1
     51: isub          
     52: istore_3      
     53: aload         4
     55: athrow        
   Exception table:
      from    to  target type
         26    27    38   Class java/lang/Exception
         19    56    19   Class java/lang/Exception

CFR and Procyon actually make a reasonable job of it, but are still both pretty wildly out.   Fernflower gives up completely and goes home.

You can see what the above does, and you can also see how it's a trivial transformation from the original bytecode - an automated obfuscator could use this trick with no work at all, and it's a lot more effective than simple renaming.

(For reference, you can get this test here).

classic illegal java rewrites (like replacing a loop with a self-vectoring exception table).

what u mean

what u mean

This.

Take a loop, remove the back jump, replace it with a catch handler at the top.  That one's fairly easy to handle.  Then, wrap the body of the loop in a boolean so it only gets executed every other time via a forward jumping exception handler.

Here's an example:

Code:

 public static void main(java.lang.String[]);
   Code:
      0: new           #16                 // class java/lang/Exception
      3: dup          
      4: invokespecial #14                 // Method java/lang/Exception."<init>":()V
      7: astore        4
      9: getstatic     #17                 // Field java/lang/System.out:Ljava/io/PrintStream;
     12: astore_1      
     13: ldc           #11                 // int 10
     15: istore_2      
     16: iconst_0      
     17: istore_3      
     18: aconst_null  
     19: pop          
     20: iload_3      
     21: ifne          27
     24: aload         4
     26: athrow        
     27: aload_1      
     28: iload_2      
     29: dup_x1        
     30: invokevirtual #24                 // Method java/io/PrintStream.print:(I)V
     33: ifne          37
     36: return        
     37: aconst_null  
     38: pop          
     39: iconst_1      
     40: iload_3      
     41: dup          
     42: ifne          51
     45: iinc_w        2, -1
     51: isub          
     52: istore_3      
     53: aload         4
     55: athrow        
   Exception table:
      from    to  target type
         26    27    38   Class java/lang/Exception
         19    56    19   Class java/lang/Exception

CFR and Procyon actually make a reasonable job of it, but are still both pretty wildly out.   Fernflower gives up completely and goes home.

You can see what the above does, and you can also see how it's a trivial transformation from the original bytecode - an automated obfuscator could use this trick with no work at all, and it's a lot more effective than simple renaming.

(For reference, you can get this test here).

whats the performance for this method, it would be slower i assume?
also is there a paper or something on this concept

whats the performance for this method, it would be slower i assume?
also is there a paper or something on this concept

It would certainly be slower, yes.  That's often a price obfuscators are prepared to pay.

I can't remember off the top of my head where I first saw this described, however have a quick google. (eg).

http://www.zelix.com/klassmaster/docs/ob...#exception

http://journal.info.unlp.edu.ar/journal/...ul08-3.pdf (describes for msil, but the technique is obviously similar.)

For what it's worth - I don't actually test CFR against any obfuscated code due to potential legality issues - I test against my own implementations of concepts such as this, as well as other sorts of evil thoughts that pop into my head (i.e. putting completely inaccurate information in type table, marking every method as synthetic, etc.).