1 / 31

Self-Protecting Mobile Agents

Self-Protecting Mobile Agents. Tom Van Vleck Lee Badger Doug Kilpatrick Larry D’Anna Brian Matt. Funded by both OASIS and Active Networks Programs NAI Labs March 2002. Not for Public Release. Web Server. Code Red. Problem and Objective. Running Agent.

kyoko
Download Presentation

Self-Protecting Mobile Agents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Self-Protecting Mobile Agents Tom Van Vleck Lee Badger Doug Kilpatrick Larry D’Anna Brian Matt Funded by both OASIS and Active Networks Programs NAI Labs March 2002 Not for Public Release

  2. Web Server Code Red Problem and Objective Running Agent • Problem: Mobile programs are vulnerable to tampering by hosts on which they run. • Objective: Protect mobile agents from tampering while allowing: Code Data Agent Execution Server Attack Attack Host Operating System • High mobility. • Detached operation. • Extended deployment periods. • Realistic infrastructure requirements.

  3. agent Host Traditional Agent Technical Approach (in a nutshell) agentlet 1 agentlet 2 agentlet 3 agentlet N ... Host Host Host Host Self-Protecting Agent • Distribution: replicate agents across multiple, unrelated hosts. • Present a moving target • Monitoring/Recovery: regenerate corrupted “agentlets.” • Code/data Obfuscation: prevent host-based analysis • Refresh obfuscation before analysis can be completed

  4. Source Code Obfuscation Transform Obfuscated Source code Run for n seconds Stop. Policy A Time-limited Black Box De-obfuscation takes m >> n seconds Hohl, Fritz, “An Approach to Solve the Problem of Malicious Hosts” • A host can deny execution, or lie, but it can’t disrupt the programs’ internal consistency for n seconds.

  5. Goals of Obfuscator • Prevent understanding of • Implementation structure • Data values • Algorithms • For some amount of time (work) • Not a toy

  6. Obfuscator Non-Goals • As strong as cryptography • Smaller or faster than original • Weak obscurity -> strong protection Barak, Goldreich, et al, CRYPTO 2001: “Obfuscation is impossible.” … for their definition Random slashdot poster sl956: “… We all know that anybody using the words 'tamper resistant' to describe a software-based solution is incompetent at best. ...”

  7. What We’ve Done Lately • Obfuscation Techniques Evaluation Report • Jbet obfuscation tool • Obfuscation transforms • Control, data • Packaging • Modular architecture • Automated test suite (197 tests, one with >300 cases) • Nightly build

  8. Jbet Obfuscation Tool - Context obfuscated classes classes JBET Plugin Transforms Obfuscation policy

  9. Obfuscation Pipeline Reader classes DAG Control flow Obfuscations xforms xforms DAG DAG Variable obfuscations Code Gen classes Optimization & obfuscation

  10. DAG Representation Node Node Node Basic block params Node Node Basic block method Node Basic block Node Node Node Node params Basic block Node Node Node method Basic block Node Node

  11. Obfuscation Transforms • Transient Variable Obfuscation • Offset, CRT, XOR, etc • Control Flow Obfuscation • Switchify, method and class merging • Method combination • Field access • Introduction of dummy blocks • Name regeneration

  12. Control Flow • No method calls except • A few utility calls • Calls to external classes • Internal simulated call stack • Stub classes passed to external methods

  13. Control Flow Obfuscation: Switchify A condition_1 switch D condition_2 A D C B E exit condition_1 condition_2 C B E

  14. Merged Methods push() pop() push() pop() internal() make_ frame() free_ frame() alloc() free()

  15. Class Merging • Classes with native methods left separate • Internal classes fully emulated, vanish

  16. Method Calls • Simulated call stack • Virtual methods become table of function addreses, stored as fields, subject to further obfuscation • Alternative virtual dispatch mechanisms

  17. Field Access • All variables replaced by refs to storage container class. class Memory { int[] I; float[] F; Object[] L; long[] J; double[] D; memory[] N; }

  18. Exceptions • Semantics preserved but athrow not used • Try/catch/throw internal to a method • Handler address known statically • General • Emulated with dynamic list of active handlers

  19. Simple Demo public class Test { public static void main(String[] a) { for (int i = 0; i < 10; i++) { System.out.println(i); } } • This is a hard program to obfuscate • Transient variable obfuscation is easy to see through. • Control flow obfuscation really works • Program grows in size

  20. Hard Demo • DES test (public domain code) • 6 classes, 3179 lines • More obfuscation • Code volume and runtime increase

  21. Demo

  22. Results - Simple

  23. Results - DES

  24. What’s Next • More transforms • Plug-in architecture • Optimum determination of transforms • Data flow driven • Metrics • Speed and space improvement • Integrate with agentlets

  25. 2000 2001 2002 2003 March 14, 2000 Start Date March 15, 2003 End Date Administrative Info (Milestones) a a April 30, 2001 Prototype Distributed Agent Generation Tool Nov. 15, 2001 Obfuscation Techniques Evaluation Report Jan. 15, 2003 Final Report a Feb. 28, 2001 Policy Specification and Architecture Report a March 15, 2002 Obfuscated Agentlet Prototype Dec. 15, 2002 Distributed, Self-Healing Obfuscated Agentlet Prototype

  26. The End!

  27. Commercial Obfuscators & Decompilers • Severe limitations • Obfuscation mostly limited to name removal

  28. Deferred Java Features • Floating point • Reflection • Serialization • Synchronization

  29. Java Challenges • Typed memory management • Java verifier • Forces correct type and stack at every point • Limited control flow • Rich program object

  30. Static and Dynamic • Static analysis • Branch loses information of where from • Trace based analysis • Program slicing • Interpretive execution for given input • Threading • Separate thread for interactions with environment • Nondeterministic execution

  31. obfuscation transform … … … … … Ideal State Obfuscation P OP

More Related