1. Java Obfuscating Techniques Michael Batchelder 3 / 3 / 2006

2. Presentation Outline ● Introduction and Motivation ● Previous Work ● Current Efforts ● Future Directions

3. Introduction and Motivation ● Java bytecode – Intermediate representation. – Inherently more insecure due to it's portable nature ● hard to implement TCG initiative – More readable than machine code ● Represents an abstracted view of assembly ● Removes the need to know specific architectures

4. Introduction and Motivation ● Java bytecode – JVMTI makes it easy to “watch” the execution of a program – There is no standard protection mechanism such as encryption – There will always be evil-doers that would like to steal your code: DAVA

5. Introduction and Motivation ● Obfuscate \Ob*fus"cate\, – To darken; to obscure; to becloud. – Technologically speaking: ● obfuscation obscures the true inner workings of software programs. – Obfuscation provides security by obscuring ● High level program structure (OOD & patterns) ● Low level control flow ● Data structures – Maybe even the data itself

6. Introduction and Motivation ● Important Goals: ● Maintain semantics ● Maintain performance ● size ● speed ● memory usage ● BREAK the decompilers!

7. Previous Work ● Breaking Abstractions and Unstructuring Data Structures – Collberg and Thomborson ● Introduced some basic ideas: – False refactoring (dumby parents / methods) – Array restructuring (split, fold, flatten) – Inline/Outline methods ● MX(x1, x2, x3) and MY(y1, y2) becomes MX(x1, x2), MZ(x3, y1) and MY(y2) – Variable splitting and merging – Convert static to procedural data ● Methods that build “constants”

8. Previous Work ● Watermarking, Tamper-proofing, and Obfuscation – Collberg and Thomborson ● Framework for obfuscation techniques: – Semantics preserving – Maximize obscurity – Maximize resilience ● Ability to thwart reverse engineering – Maximize stealth ● similar statistical properties of original code

9. Previous Work ● Lexical control transforms – Name changing – Opaque predicates ● Data transforms – Split booleans into multiple numerics ● Tamper-proofing – Detect if program has been altered – Cause failure

10. Previous Work ● Java Obfuscation with a Theoretical Basis for Building Secure Mobile Agents – Sakabe, Soshi, Miyaji ● Exploiting Polymorphism – Introduce: ● new “Rt” class for all return types ● new “arg” class with subclass for each app class ● dumby methods so every class has same # ● name all methods in app classes the same ● “Rt” encapsulates correct type/value ● “arg” encapsulates all args for method

11. Previous Work ● Try/Catch exceptions as if replacement

12. Previous Work ● Empirically – Significantly larger (3x) – Significantly slower (1.3x)

13. Previous Work ● Obfuscation of Design Intent in OO Applicatons – Sosonkin, Naumovich, Memon ● Exploiting Polymorphism – Class coalescing: ● Combine multiple classes into one – This can increase memory consumption – Class splitting: ● Replace a single class with multiple ones – Chained through inheritance ● Arguably, this “object-orientifies”

14. Previous Work ● Exploiting Polymorphism some more – Type Hiding through interfaces ● Introduce multiple interfaces for the same class ● Each interface contains small subset of methods ● Empirically: ● Splitting does not effect performance ● Coalescing does ● type hiding, sometimes: – Large amounts of casting within nested loops

15. Presentation Outline ● Introduction and Motivation ● Previous Work ● Current Efforts ● Future Directions

16. Current Efforts ● Renaming: – Could exchange method/field names ● get becomes set, etc – Instead, introduce garbage names ● S5$S$5$$ is hard to distinguish from SS$S$5$$ ● __________ is hard to distinguish from _________

17. Current Efforts drawbranch(g, width, (int)x, w1H-(int)y, (int)x1, w1H-(int)y01); turtle_r = height; turtle_theta = point(x, y, x1, y01); turtle_x = x; turtle_y = y; turn(left_angle); __________(r1, $SS$$, (int) ___________, SSSS5 - (int) S55S5, (int) $5S$$, SSSS5 - (int) SSS5$); $$$S5 = ______; S$S55 = ______(___________, S55S5, $5S$$, SSS5$); ____________ = ___________; S5SS$ = S55S5; ___________($SSS$);

18. Current Efforts ● Method obscuring: – Some methods can't be renamed ● library calls – Instead, introduce level of indirection ● Select random application class ● Add new method which then calls the library call

19. Current Efforts ● Object obscuring: – Introduce intermediate classes ● subclass library classes ● superclass application classes public class Fractal extends Frame becomes: public class _____ extends l1Ill

20. Current Efforts public class l1Ill extends java.awt.Frame { public l1Ill( ) { super( ); } public void paint (java.awt.Graphics r1) { Illl1(r1); } public java.lang.String toString( ) { return IlI1I( ); }

21. Current Efforts ● Library call obscuring: – Introduce intermediate methods (randomly) ● Static methods which call library methods – Expensive, space-wise! java.io.PrintStream out; out.println(string); becomes a call to: public static void I1I1l(String s, PrintStream p) { p.println(s); }

22. Current Efforts Quick Empirical Results ● Fractal – a quick fractal tree generator – Large amounts of floating point ops – Very little Object creation Original: 8.71 secs, 5121 bytes Obfuscated:8.92 secs (2.4%), 4779 bytes Obfus w/lib:9.07 secs (4.1%), 6369 bytes DavaRcmpld:9.14 secs,(5.0%), 7568 bytes

23. Presentation Outline ● Introduction and Motivation ● Previous Work ● Current Efforts ● Future Directions

24. Future Directions ● Method and Field movement – Randomly move static fields/methods to other classes – Use static fields to hide arguments ● If replacement with Try/Catch or Switch – Avoid performance penalty by creating static exceptions ● “throw existingExc” vs. “throw new Exception()”

25. Future Directions ● Method Control Flow obfuscation – Try/Catch & Switch blocks in bytecode do not have to be sequentially ordered..catch from label1 to label2 using label3.catch from label4 to label5 using label3 label1: iconst_0 istore_0 label2: goto label0 label3: astore_0 label4: aload_0 astore_0 label5: Also: – Exploit jsr bytecode

26. Future Directions ● How do we measure results? – Introduce metrics to measure “complexity” of a program (aka “potency of obfuscation”) ● OOD metrics – how “spaghettified” are the classes ● How convoluted is the control flow per method ● Max nesting depth, average nesting depth ● Number of locals used ● Complexity of if conditions

27. The End