Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Droidcon Greece '15 - Reverse Engineering in Android: Countermeasures and Tools

1,935 views

Published on

Reverse Engineering (RE) is the art of taking an application apart and try to understand the internal mechanisms.

There’s a positive side and a negative side to this approach. The positive side is the fact that RE gives us a means to research and understand malware.

The negative side is that distributed binaries can be torn apart to look at intellectual property or to inject it with malicious code.

The talk will guide you through the Android app build process and learn some countermeasures to make it harder for hackers to reverse engineer your Android code. Further more the talk will cover opensource tools that you can use to reverse engineer Android applications to inspect it for malware.

Published in: Software
  • Be the first to comment

Droidcon Greece '15 - Reverse Engineering in Android: Countermeasures and Tools

  1. 1. 10-12 September 2015 droidcon Greece Thessaloniki
  2. 2. Reverse Engineering in Android Countermeasures and Tools
  3. 3. > Dario Incalza (@h4oxer) > Application Security Engineering Analyst > Android Developer $ whoami
  4. 4. CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
  5. 5. > Good Guys: > Understand Malware > Security Research > Bad Guys: > Piracy > Steal Intellectual Property > Introduce backdoors MOTIVATION
  6. 6. > Law is a gray area! > Depends on country > Depends on purpose (i.e. achieve interoperability) > End User License Agreement (EULA) > Takes away all doubt > Almost always illegal > For educational purposes ;-) IS IT LEGAL?
  7. 7. CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
  8. 8. Android Application Anatomy .zip file Android Package (.apk) classes.dex resources. arsc Compiled resources Dalvik byte code AndroidManifest.xml Binary version of AndroidManifest.xml uncompiled resources Native Libraries Third-party .so libraries
  9. 9. Android Build Process
  10. 10. > classes.dex is executed > Dalvik <-> ART (since Android 4.4) > Optimize code for execution > Dalvik: Just-in-Time (JIT) > ART : Ahead-of-Time (AOT) Application Execution
  11. 11. Application Execution JIT AOT
  12. 12. CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
  13. 13. Reverse Engineering APK RE Tools Dalvik ByteCode Java Code Smali/Jasmin Native Code
  14. 14. Reverse Engineering – Dalvik ByteCode RE Tools Dalvik ByteCode Java Code Smali/Jasmin
  15. 15. Reverse Engineering – Smali RE Tools Dalvik ByteCode Java Code Smali/Jasmin
  16. 16. Reverse Engineering RE Tools Smali/Jasmin Native Code To which format do I RE the .APK? > Depends on what you want to achieve > Understanding internal mechanisms => Java Code > Instrumenting apps => Dalvik/Smali Bytecode/Jasmin > Native libraries => RE the .so library to native code Usually a combination of all
  17. 17. Reverse Engineering RE Tools Smali/Jasmin Native Code RE Java Code Information < Original Java Code Information Reason: Information loss when building classes.dex from .class Consequence: Impossible to rebuild RE Java Code, use Dalvik Byte Code format instead
  18. 18. Reverse Engineering RE Tools Smali/Jasmin Native Code How does a regular RE process looks like?
  19. 19. Reverse Engineering – First Step: Objectives RE Tools Smali/Jasmin Native Code Who wrote the app? What permissions does it use and why does it need them? Is it using crypto, if so, what is it encrypting? Is it using reflection, if so, why is it using reflection? Is it using dynamic bytecode loading, if so why is it using it? Is it using obfuscation? Is it malware?
  20. 20. Reverse Engineering – Second Step: Info gathering RE Tools Smali/Jasmin Native Code > Don’t jump to looking at code in the wild! > app name, icon, activities, receivers, services, permissions, intents (AndroidManifest.xml) > strings.xml > native .so libraries > signature of the app
  21. 21. Reverse Engineering – Third Step: Hacking Time RE Tools Smali/Jasmin Native Code Now experience comes into play > decompile classes.dex or .so libraries > Find entry-points > Search for dynamic bytecode loading, permission usage, reflection, crypto code
  22. 22. CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
  23. 23. Use Case RE Tools Smali/Jasmin Native Code AnserverBot Trojan (August 2011 - Yajin Zhou, Xuxian Jiang )
  24. 24. Use Case - AnserverBot Trojan RE Tools Smali/Jasmin Native Code Dynamic Bytecode Loading Reflection C&C ServerAggressive Obfuscation
  25. 25. Use Case - AnserverBot Trojan RE Tools Smali/Jasmin Native Code Background Service Dynamically Loaded
  26. 26. Use Case - AnserverBot Trojan $ unzip anserverbot_sample.apk $ cd assets Payload A Payload B
  27. 27. Use Case - APKTool $ apktool d anserverbot_sample.apk
  28. 28. Use Case - AnserverBot Trojan - AndroidManifest SUSPICIOUS
  29. 29. Use Case - AnserverBot Trojan - AndroidManifest SUSPICIOUS
  30. 30. Use Case - AnserverBot Trojan - Payloads Anservera.db and Anserverb.db are not database files. Zip archives? => Android apps
  31. 31. Use Case - AnserverBot Trojan - Payloads $ apktool d anservera.db
  32. 32. Use Case - AnserverBot Trojan – Dynamic Bytecode Loading Payloads == Android code => Dynamic Bytecode loading! Use ARES (Android Reverse Engineering Suite) or Androguard!
  33. 33. Use Case - AnserverBot Trojan - ARES Payload A uses Dynamic Bytecode Loading AND Reflection
  34. 34. Use Case - AnserverBot Trojan - ARES Lcom/sec/android/providers/ drm/Style -> a() Lcom/sec/android/providers/ drm/Style -> b() Lcom/sec/android/providers/ drm/Style -> c()
  35. 35. Use Case - AnserverBot Trojan Next steps: > Look at the methods a(), b() and c() > You’ll see obfuscation and encryption > Use symbolic execution to get rid off encryption > I.e. Simplify
  36. 36. Use Case – Simplify “ If an app's strings are encrypted, Simplify will interpret the app in its own virtual machine to determine semantics. Then, it uses the apps own code to decrypt the strings and replaces the encrypted strings and the decryption method calls with the decrypted versions.” https://github.com/CalebFenton/simplify
  37. 37. Use Case – Anserverbot Trojan – C&C Command & Control (Phone Home) Goal: Keep control, update payloads and push back info Server addresses are hardcoded but encrypted > Custom Base64 encryption What to do?
  38. 38. Use Case – Decompile with Simplify Smali from APK Simplify Smali Files Classes.dex JAR dex2jar JAD Eliminates useless code, encryption, makes code more readable
  39. 39. Summary Tools Androguard: Reverse Engineering API written in Python, comes with a shell ARES: Android Reverse Engineering Suite, build on Androguard Simplify: Symbolic code executioner, rewrites code to simplify and eliminate encryption, dead/useless code. DEX2JAR/DEX2JASMIN/DEX2SMALI: Transform classes.dex to intermediate code
  40. 40. Summary Tools JEB: Android Reverse Engineering Suite (Commercial) Radare: Reverse Engineering Tool, Android support APKTool: Automate decompilation of resources and classes.dex to smali APKStudio: An IDE for decompiling/editing & then recompiling of android application binaries.
  41. 41. CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
  42. 42. COUNTERMEASURES How to protect your code once it is distributed? No silver bullet =(
  43. 43. COUNTERMEASURES > Tamper detection > Dynamic Bytecode Loading > Obfuscation > Anti-debugging > Code/String Encryption > Code Guards
  44. 44. COUNTERMEASURES – TAMPER DETECTION > Detect app modification/repacking > APKTool makes it easy to repack > What if we could detect rebuild/recompilation/repackaging? Source: BlueBox Security
  45. 45. COUNTERMEASURES – TAMPER DETECTION Idea: Use the AndroidManifest.xml > Purpose: provide metadata: permissions, activities, services, etc. > Compiled to binary format in APK > During build: text => binary (aapt) > What about binary to text? (apktool)
  46. 46. COUNTERMEASURES – TAMPER DETECTION > When parsed by Android, attributes are identified according to an id: <public type="attr" name="name" id="0x01010003" /> > Inject a “name” attribute into <application> with an unknown id, Android will not recognize it as a name attribute.
  47. 47. COUNTERMEASURES – TAMPER DETECTION > Result: Android will parse manifest just fine, APKTool will include a proper “name” attribute when rebuilding APK > Executing a rebuild APK with APKTool will execute the injected name (i.e. detect.class) and thus trigger an alarm
  48. 48. COUNTERMEASURES – TAMPER DETECTION <application> <activity android:name= "com.example.manifestexample.MainActivity"> <intent−filter> <action android:name= "android.intent.action.MAIN" / > </intent−filter > </activity> </application> < application android.name=“detect.class”>
  49. 49. COUNTERMEASURES – Dynamic Bytecode Loading > Code that is not statically available cannot be RE > Use Dynamic Bytecode Loading for critical code > Ship code as encrypted asset > Attack: dump code from memory > Tool: DABiB – Dynamic Android Binary Debugger
  50. 50. COUNTERMEASURES – Obfuscation > Idea: transform source or byte code to human unreadable but semantically equivalent code > Inject useless code > Disrupt call graph flow by using reflection and dynamic bytecode loading > Encrypt assets and libraries > Class/String Encryption
  51. 51. COUNTERMEASURES – Obfuscation > Tools: ProGuard/DexGuard, Arxan, DashO, Allatori, Stringer > Attack: Decompile code and start with entry-point, refactor through code, use Simplify
  52. 52. COUNTERMEASURES – ANTI-DEBUGGING > Idea: detect debugging environment > Different behavior than in non-debugging environment > Only works if you know the execution environment (we do) > Tools: DexGuard Enterprise, Arxan
  53. 53. COUNTERMEASURES – Code/String Encryption
  54. 54. COUNTERMEASURES – Code/String Encryption Packers Stub Application Hidden Encrypted Code Stub Application Decrypted Code Static Dynamic Execution
  55. 55. COUNTERMEASURES – Code/String Encryption Packers (Bangcle, Pangxie) > Static analysis is hard > Code can still be dumped from memory after unpacking on runtime > Slows attacker down > Tools: DexGuard, Arxan, Stringer, Allatori
  56. 56. COUNTERMEASURES – Code Guards > Inject guards in bytecode > Protect and check program flow > Re-initialize critical values > Detect hooks > Check signature > Check app checksum > Tool: Arxan
  57. 57. COUNTERMEASURES – Conclusion > Security should be a requirement in SDLC > Work towards thin Android apps > Business critical code on server > Deploy countermeasures to slow down RE
  58. 58. YOUR AVATAR or YOUR PHOTO Dario Incalza Application Security Engineering Analyst LSEC – Leaders in Security @h4oxer Thank you! droidcon Greece Thessaloniki

×