Your SlideShare is downloading. ×
Owaspeutour2013lisbon pedrofortunaprotectingjavascriptsourcecodeusingobfuscation-130625180450-phpapp02
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Owaspeutour2013lisbon pedrofortunaprotectingjavascriptsourcecodeusingobfuscation-130625180450-phpapp02


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Protecting JavaScript source code using obfuscation Facts and Fiction Pedro Fortuna, Co-Founder and CTO AuditMark OWASP Europe Tour 2013 Lisbon - June 21st, 2013
  • 2. 2 Code Obfuscation concepts Code Obfuscation metrics Practical examples Outline OWASP Europe Tour 2013
  • 4. 4 Obfuscation “transforms a program into a form that is more difficult for an adversary to understand or change than the original code” [1] Where more difficult means “requires more human time, more money, or more computing power to analyze than the original program.” [1] in Collberg, C., and Nagra, J., “Surreptitious software: obfuscation, watermarking, and tamperproofing for software protection.”, Addison-Wesley Professional, 2010. Code Obfuscation OWASP Europe Tour 2013
  • 5. 5 Lowers the code quality in terms of Readability Maintainability Delay program understanding Time required to reverse it > program useful lifetime Resources needed to reverse it > value obtained from reversing it Delay program modification Cost reversing it > cost of developing it from scratch Code Obfuscation OWASP Europe Tour 2013
  • 6. 6 Obfuscation != Encryption Web Application Encryption Algorithm Decryption Algorithm JS Engine Executable JavaScript Source Code Executable JavaScript Source Code Non-Executable Encrypted Code Encryption Key Decryption Key { { { • This is a common misconception • Encrypted code is not executable by the browser or JS Engine • A decryption process is always needed OWASP Europe Tour 2013
  • 7. 7 Obfuscation != Encryption Web Application Obfuscation Engine JS Engine Executable JavaScript Source Code Executable JavaScript Source Code { { • JavaScript obfuscated code is still valid, ready to execute code • It does not require a symmetric deobfuscation function OWASP Europe Tour 2013
  • 8. 8 JavaScript Obfuscation Example #1 HTML5 Canvas example from • Being JavaScript, this code is delivered to the browser as clear text, and as such, it can be captured by anyone
  • 9. 9 JavaScript Obfuscation Example #1 • This is the obfuscated version of the code. • It can still be captured by anyone, but it is much harder to grasp and to change.
  • 10. What is it good for? Good • Prevent code theft and reuse – E.g. Stop a competitor from using your code as a quickstart to build its own • Protect Intellectual Property – Hide algorithms – Hide data – DRM (e.g. Watermarks) • Enforce license agreements – e.g. domain-lock the code • As an extra security layer – Harder to find vulnerabilities in the client-side • Test the strength of security controls (IDS/IPS/WAFs/web filters) Evil • Test the strength of security controls (IDS/IPS/WAFs/web filters) • Hide malicious code • Make it look like harmless code OWASP Europe Tour 2013
  • 11. 11 • Question often raised: why not move security sensitive code to the server and have JS request it whenever needed ? • Sometimes you can... and you should! • But there are plenty situations where you can’t: – You may not have a server • Widgets • Mobile Apps • Standalone, offline-playable games • Windows 8 Apps made with WinJS – You may not want to have a server • May not be cost effective doing computations on a server (you have to guarantee 100% uptime, support teams) • Latency Why not rely on the Server? OWASP Europe Tour 2013
  • 13. 13 • Potency • Resilience • Stealthiness • Execution Cost • Maintainability Measuring Obfuscation Next: • We’ll present each metric using simple examples • This is intentional, to ease the process of understanding the metrics • However, they do not represent to the full extent what you can obtain if you combine a large set of different obfuscation transformations. OWASP Europe Tour 2013
  • 14. 14 Generates confusion Obfuscation Potency Measuring Obfuscation • Measure of confusion that a certain obfuscation adds • Or “how harder it gets to read and understand the new form when compared with the original” • To the left you can see a simple example of a factorial function OWASP Europe Tour 2013
  • 15. 15 Generates confusion Obfuscation Potency Measuring Obfuscation Rename all + Comment removal • Now to the right you see the result of renaming every symbol to a mix of lower and upper O’s. We all know that function names and variable names are quite useful for the purpose of understanding the code. Not only we’ve lost that, but the new names can be easily confused. • Also comments were removed. They are also important to understand a program. • So we can definitely say that the obfuscation introduced a certain degree of confusion. It has added some potency.
  • 16. 16 Generates confusion Obfuscation Potency Measuring Obfuscation Rename all + Comment removal Whitespace removal • Now, below, you can see the result of removing whitespaces from the code. It becomes slightly more confusing, so we can say it is slighly more potent than the previous example.
  • 17. 17 Resistance to deobfuscation techniques be it manual or automatic Obfuscation Resilience Measuring Obfuscation • Represents the measure of the resistance that a certain obfuscation offers to deobfuscation techniques • Or “how hard it is to undo the back to the original form” • To the left you can see the same example function as before OWASP Europe Tour 2013
  • 18. 18 Resistance to deobfuscation techniques be it manual or automatic Obfuscation Resilience Measuring Obfuscation Rename all + Comment removal • On the right you can see the result of applying rename_all obfuscation. • This is an example of an obfuscation which is 100% resilient, because, assuming that you don’t have access to the original source code, it’s impossible to tell what were the original names. • The comment removal obfuscation is also 100% resilient as you can’t possibly know if the original form had any comments and recover them
  • 19. 19 Resistance to deobfuscation techniques be it manual or automatic Obfuscation Resilience Measuring Obfuscation Rename all + Comment removal String splitting• on the bottom, you see the result after applying string splitting. • You can definitly see that it is more potent than the previous, but if you look carefully, you can see that its not hard to revert back to the previous form. • So we can say that this version does not really add much resilience when compared with the previous form.
  • 20. 20 One way of attacking obfuscation is using a Static Code Analyser 1. Parses the code 2. Transforms it to fullfill a purpose – Usually to make it simpler => better performance – Simpler also fullfills reverse-engineering purpose • Example simplifications – Constant propagation, constant folding – Remove (some) dead code • And most importantly, it is automatic! Static Code Analysis for defeating obfuscation Constant propagation: x = 10; y = 7 – x / 2; x = 10; y = 7 – 10 / 2; Constant folding: N = 12 + 4 – 2; N = 14; OWASP Europe Tour 2013
  • 21. 21 • We used Google Closure Compiler, a Static Code Analyser to simplify the code. • The result is on the right, which as you can see returned much easier to read code.
  • 22. 22 • If we compare the code on the right with the original code (on the left) we can see that they are not far apart. • So the potency of the obfuscation is only apparent. The real potency or the potency we should consider is the one that you get after using automated ways of reversing the code. • This does not mean that the string-splitting obfuscation is useless. It has to be combined with other obfuscations that provide more resilience.
  • 23. 23 • Another way of attacking obfuscation • Analysis performed by executing the code – Retrieves the Control flow graph (CFG) of the code executed – Retrieve values of some expressions • How it can be used to defeat obfuscation – Understand (one instance of) the program execution • You can focus on parts that you are sure that are executed – Retrieve values of some expressions • Aids code simplification • Find needle in the haystack => e.g. retrieve encryption key – Bypasses deadcode – Not very good for automatic reversal of obfuscation • May not “see” all useful code • If you need to make sure the code will remain 100% functional, you cannot use this technique – Gather knowledge for manual reverse engineering Dynamic Code Analysis for defeating obfuscation OWASP Europe Tour 2013
  • 24. 24 • How hard is to spot? – Or “how hard is to spot the changes performed by the obfuscation” – Or “how successfull the obfuscation was in making the obfuscated targets look like other parts of the code” • An obfuscation is more stealthy if it avoids common telltale indicators – eval() – unescape() – Large blocks of meaningless text Obfuscation Stealthiness Measuring Obfuscation OWASP Europe Tour 2013
  • 25. 25 • Impact on performance – Runs per second – FPS (e.g. Games) – Usually obfuscation does not have a positive impact on performance, but it does not necessarily have a negative impact. It depends on the mix of transformations chosen and on the nature of the original source code. • E.g. Renaming symbols => Same execution cost • Impact on loading times – Time before starting executing – Usually a function of file size – Usually obfuscation tends to grow filesize. But there are also some obfuscation transformations which also makes it smaller. • E.g. Renaming symbols again Obfuscation Execution Cost Measuring Obfuscation
  • 26. 26 Effect on maintainability = 1/potency (after static code analysis) Lower maintainability => mitigates code theft and reuse This is one of the most important concepts around obfuscation Obfuscation & Maintainability Measuring Obfuscation OWASP Europe Tour 2013
  • 28. 28 Compression/Minification vs Obfuscation • This first example aims to clarify one of the most common misconceptions around obfuscation: a lot of people do not understand very well the difference between compressing or minifying the code and obfuscating it. • This code is a portion of a md5 function in JavaScript.
  • 29. 29 Compression/Minification vs Obfuscation • This is a compressed version of it • It really seems to be more potent. No doubt about it.
  • 30. 30 Compression/Minification vs Obfuscation • But look, it has got an eval() on it. Not much stealthy. • It is needed because the javascript has been encoded and the result of decoding it must be evaluated in runtime. • When encoding is used, there is always a decoding function somehwere. • The real questions is: Is it resilient ?
  • 31. 31 eval( (function(....)) ); document.write(‘<textarea> (function(...)) </textarea>’); A simple trick will do it • By replacing the eval() with a document.write (just one way to do it) you get access to the decoded source. OWASP Europe Tour 2013
  • 32. 32 Reverse-engineered result Original source • And that results in the code you see on the right. If you compare with the original source code, you can see that it’s pretty much the same code. • To many this isn’t surprising, but a lot of people uses JavaScript compressors or minifiers with the intention of protecting the code. • This is perfect example of a code transformation that is very potent but with almost null resilience. • Compressor/Minifier tools do not aim at protecting the code. Their sole purpose is to make it smaller and faster.
  • 33. 33 • First JavaScript version proposed by Yosuke Hasegawa (in, Jun 2009) • Encoding method which uses strictly non-alphanumeric symbols • Example: alert(1) (obfuscated version below) Non alphanumeric Obfuscation
  • 34. 34 • Using type coercion and browser quirks • We can obtain alphanumeric characters indirectly How is that possible ? +[] -> 0 +!+[] -> 1 +!+[]+!+[] -> 2 Easy to get any number +”1” -> 1 Type coercion to number “”+1 = “1” Type coercion to string How to get letters? +”a” -> NaN +”a”+”” -> “NaN” (+”a”+””)[0] -> “N” Ok, but now without alphanumerics: (+”a”+””)[+[]] -> “N” How to get an “a” ? ![] -> false ![]+“” -> “false” (![]+””)[1] -> “a” (![]+””)[+!+[]] (+(![]+"")[+!+[]]+””)[+[]] -> “N” eval( (![]+"")[+!+[]]+"lert(1)"); OWASP Europe Tour 2013
  • 35. 35
  • 36. 36 • “eval” uses alphanumeric characters! • eval() is not the only way to eval() ! • You have 4 or 5 methods more • Examples – Function("alert(1)")() – Array.constructor(alert(1))() – []["sort"]["constructor"]("alert(1)")() • Subscript notation • Strings (we already know how to convert them) Wait... What about the eval ? OWASP Europe Tour 2013
  • 37. 37 Let me see that again! OWASP Europe Tour 2013
  • 38. 38 • 100% potent • 0% stealthy (when you see it, you know someone is trying to hide something) • High execution cost – eval is a bit slower – But the worst is: file is much larger => slower loading times • May not work in all browsers • What about resilience ? – Unfortunately, not much (you can get a parser to simplify it back to the original source) • Good for bypassing filters (e.g. WAFs) Non alphanumeric Obfuscation OWASP Europe Tour 2013
  • 39. 39 Original source code Deadcode injection + Rename localDeadcode injection Can you spot where is the dead code ?
  • 40. 40 Original source code Deadcode injection + Rename localDeadcode injection
  • 41. 41 • Deadcode insertion is a natural way of adding confusion to a source code, and thus increasing the potency of obfuscation. • Being deadcode, the code isn’t really executed, so this has no impact on Execution Cost • Would a Static Code Analyser remove this particular dead code? • No, because it relies on opaque predicates – Not removable using Static Code Analysis – Predicates similar to ones found in the original source ( ++stealthiness ) • Randomly injected ( ++potent ) • Increase complexity of control flow ( ++potent ) • Dummy statements created out of own code (++potent & ++stealthiness ) Deadcode injection OWASP Europe Tour 2013
  • 42. 42 All Together Now HTML5 Canvas example from • Up to now we have mostly seen no more than two or three obfuscation transformations working together. • Let’s go back to the first example and see what happens when we mix a larger number of code obfuscation transformations together.
  • 43. 43 All Together Now • remove comments • dot notation • rename local • member enumeration • literal hooking :low • deadcode injection • string splitting :high • function reordering • function outlining • literal duplicates • expiration date "2199-12-31 00:00:00"
  • 44. 44 All Together Now • As you can see, you get and heavily obfuscated result. • We intentionally didn’t used any encoding- based obfuscation in this example to let you see the effect of these transformations together. Also, you are not seeing the whole code here. • For the record, not all encoding transformations are easily reversed. We could use for instance a Domain-lock encoding which needs to get the correct information from the browser to decode properly.
  • 45. 45 After Closure Compiler • And this is the result after running the code through Google Closure Compiler. • It didn’t improved the readability much because the obfuscation transformations offered a good degree of resillience.
  • 46. 46 • People often judge obfuscation based on its (aparent) potency • Its resilience and the “real” potency that matters – Potency that you get after applying automated tools to reverse it • Evaluating resilience is not trivial – Looking at simpler examples it may be relatively easy “at naked eye” to tell which of two obfuscations is more resilient – But looking when comparing complicated obfuscated versions, that use many code transformations, its not easy to say which version is more resilient. – This is a job for JavaScript obfuscators • They should offer not only potency, but also resilience • Make an effort to explain its users what is best to protect their code • Avoid making available options that may reduce resilience Conclusion OWASP Europe Tour 2013
  • 47. 47 • Don’t forget execution cost – And where the code is executed. A Smartphone usually has less resources than a desktop computer. Obfuscation should be tuned to the platform where the code is being executed. • Obfuscation can be very effective as a way to prevent code theft and reuse, by – Making it a real pain to understand of the code – Making it a real pain to change the code successfully – Significantly lower the value that can be obtained by an attacker from reversing a code Conclusion OWASP Europe Tour 2013
  • 48. Contact Information Pedro Fortuna Owner & Co-Founder & CTO Phone: +351 917331552 Porto - Headquarters Edifício Central da UPTEC Rua Alfredo Allen, 455 4200-135 Porto, Portugal Lisbon office Startup Lisboa Rua da prata, 121 5A 1100-415 Lisboa, Portugal