Java Attacks & Defenses - End of Year 2010 Presentation

1,326
-1

Published on

Decompilation is a problem for the software industry, with the global revenue loss due to software piracy estimated to be more than $50 billion in 2008. There are several Java decompilers available but none are 100% effective, and many are obsolete/unmaintained. We found Java Decompiler, JODE and Dava to be good Java decompilers but not perfect. Dava is particularily suited to aribtrary bytecode, while others are suited to javac generated bytecode.

Static watermarking techniques can be used to protect a program from being copied by giving the ability to easily identify the owner of such software. However, static watermarking techniques are higher susceptible to semantics-preserving transformations. We show that the majority of the current implementations of watermarking systems are based on static techniques are fail when attacked with obfuscations and optimisations. Further work will involve evaluating dynamic watermarking algorithms in a similar manner, and compare them to their static counterparts.

Techniques such as program slicing can be used to attack software watermarks, in subtractive attacks on software.

Published in: Technology, Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,326
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Java Attacks & Defenses - End of Year 2010 Presentation

  1. 1. Java Software Attacks & Defences James Hamilton, PhD Student 0 1 0 0 0 0 1 1 0 1 1 0 0 0 1 0 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 0 1 0 0 0 1 1 1 0 1
  2. 2. Year 1 - Recap <ul><li>Survey of (Java) decompilation
  3. 3. I tested 10 different decompilers with the latest Java class file format using 10 different test programs, extending a 2003 survey.
  4. 4. Assign a value to the decompiled programs depending on the accuracy of decompilation. </li></ul>software company software thief
  5. 5. <ul><li>many of the current decompilers cannot parse the latest class files </li><ul><li>4 obsolete
  6. 6. 3 unmaintained </li></ul><li>no currently maintained commercial decompilers
  7. 7. best decompiler? depends on the tool which generated the class file </li><ul><li>Dava for arbitrary bytecode
  8. 8. Java Decompiler or JODE for javac bytecode </li></ul></ul>Year 1 – Recap - Results
  9. 9. SCAM2009 <ul><li>9 th IEEE International Working Conference on Source Code Analysis and Manipulation.
  10. 10. Leading conference in my field.
  11. 11. My first published paper 'An Evaluation of Current Java Decompilers'
  12. 12. Co-Located with 25 th IEEE International Conference on Software Maintenance
  13. 13. http://whoyouknow.co.uk/uni/phd/papers/JavaBytecodeDecompilerSurvey.pdf </li></ul>
  14. 14. Edmonton, Alberta, Canada <ul><li>Capital of Alberta. Also know as “Deadmonton”.
  15. 15. Home to the huge University of Alberta - 50 city blocks with over 90 buildings
  16. 16. & West Edmonton Mall – the world's 5 th largest mall </li></ul>
  17. 17. <ul><li>Not much improvement in 6 years </li><ul><li>all decompilers aren't very good </li></ul><li>Problems caused by newer class file specification
  18. 18. Different decompilers for different problems
  19. 19. But they still pose a security risk to Java applications </li></ul><ul><li>can we produce a decompiler which combines the best of javac decompilers and arbitrary decompilers?
  20. 20. do we really need to perform type inference if the only condition is that we require re-compilable code?
  21. 21. are the problems with the Java decompilers fundamental or just bugs? </li></ul>Paper Conclusion Questions
  22. 22. My Decompiler <ul><li>Based on the ASM bytecode manipulation framework [1]. </li><ul><li>Load & manipulate or generate classes
  23. 23. Visitor pattern </li></ul><li>1 st Task – decompile the 10 programs in 'Decompiling Java' [2]
  24. 24. Task 1 completed + decompilation of some other simple programs including for-loops, ifs, exception handling.
  25. 25. Cannot decompile all the test programs from my first paper.
  26. 26. Slow progress, currently on hold.
  27. 27. Extremely useful in understanding the problems of implementing a decompiler.
  28. 28. I found that ASM is probably not the best framework to use – the visitor API made some things hard to do.
  29. 29. Will probably port to Byte Code Engineering Library (BCEL) [3] </li></ul>[2] G. Nolan, Decompiling Java . APress, 2004. [1] http://asm.ow2.org/ [3] http://jakarta.apache.org/bcel/
  30. 30. Software Watermarking
  31. 31. Software Watermarking – Aims <ul><li>Does not prevent a program from being copied
  32. 32. But does provide a way to prove ownership of a program
  33. 33. Can prove the individual who copied the program (Fingerprint Mark)
  34. 34. Obfuscation aims to make a program hard to understand and/or decompile </li></ul>Software Watermarking vs Obfuscation
  35. 35. An Evaluation of Static Java Bytecode Watermarking <ul><li>Evaluation of the currently available Java bytecode static software watermarkers </li><ul><li>Sandmark (Academic/Open-Source)
  36. 36. Allatori (Commercial)
  37. 37. DashO (Commercial) </li></ul><li>Watermarked 60 programs with 14 watermark algorithms
  38. 38. 588 out of 840 combinations with watermarks embedded correctly
  39. 39. Obfuscated the watermarked programs with 36 obfuscations, 1 optimisation and 2 obfuscation combinations.
  40. 40. 23,626 correctly obfuscated
  41. 41. Attempted to recognise watermarks from all the obfuscated programs </li></ul>
  42. 42. Evaluation Results <ul><li>Submitted to SCAM2010
  43. 43. http://whoyouknow.co.uk/uni/phd/papers/JavaBytecodeWatermarkingSurvey.pdf </li></ul>
  44. 44. International Conference on Software Engineering (ICSE) 2010 More details about my trip at http://whoyouknow.co.uk/uni/phd/icse2010/
  45. 45. Dynamic Software Watermarking <ul><li>Embeds code to generate a watermark at run-time.
  46. 46. 3 algorithms implemented in Sandmark.
  47. 47. Should be resilient to semantics-preserving transformations.
  48. 48. . </li></ul>
  49. 49. Paper rejected <ul><li>3 long reviews with lots of points to improve the paper
  50. 50. Range of views: borderline, weak reject, reject.
  51. 51. Some problems include </li><ul><li>Introduction too long
  52. 52. There is two evaluations in one
  53. 53. Didn't take into account space/time costs
  54. 54. Didn't analyse the interactions between obfuscation/watermark pairs
  55. 55. Programs might be too small/too similar (all were jEdit plugins) </li></ul></ul>
  56. 56. Current Plan <ul><li>Extend paper to a full survey of static + dynamic watermarking
  57. 57. Add the dynamic algorithms in Sandmark to the evaluation
  58. 58. Split the evaluation into </li><ul><li>Robustness of watermark embedders
  59. 59. Robustness of recognisers
  60. 60. Resilience to semantics preserving transformations
  61. 61. Space/Time costs
  62. 62. Stealthiness </li></ul><li>Detailed analysis of the ways that the different transformations interact.
  63. 63. Compare dynamic vs static watermarks
  64. 64. Leading to </li><ul><li>A better paper and thesis chapter
  65. 65. Further work will include slicing watermarks (possibly linking with Sebastian's work on slicing) </li></ul></ul>
  66. 66. Any questions? Thanks

×