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.

1. 10-12 September 2015
droidcon Greece
Thessaloniki

2. Reverse Engineering in Android
Countermeasures and Tools

3. > Dario Incalza (@h4oxer)
> Application Security Engineering Analyst
> Android Developer
$ whoami

4. CONTENTS
> Motivation
> Android App Anatomy and Building Process
> Reverse Engineering
> Tools with Use Case
> Countermeasures

5. > Good Guys:
> Understand Malware
> Security Research
> Bad Guys:
> Piracy
> Steal Intellectual Property
> Introduce backdoors
MOTIVATION

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. CONTENTS
> Motivation
> Android App Anatomy and Building Process
> Reverse Engineering
> Tools with Use Case
> Countermeasures

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. Android Build Process

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. Application Execution
JIT AOT

12. CONTENTS
> Motivation
> Android App Anatomy and Building Process
> Reverse Engineering
> Tools with Use Case
> Countermeasures

13. Reverse Engineering
APK RE
Tools
Dalvik
ByteCode
Java Code
Smali/Jasmin
Native Code

14. Reverse Engineering – Dalvik ByteCode
RE Tools
Dalvik ByteCode
Java Code
Smali/Jasmin

15. Reverse Engineering – Smali
RE Tools
Dalvik ByteCode
Java Code
Smali/Jasmin

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. 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. Reverse Engineering
RE Tools
Smali/Jasmin
Native Code
How does a regular RE process
looks like?

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. 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. 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. CONTENTS
> Motivation
> Android App Anatomy and Building Process
> Reverse Engineering
> Tools with Use Case
> Countermeasures

23. Use Case
RE Tools
Smali/Jasmin
Native Code
AnserverBot Trojan
(August 2011 - Yajin Zhou, Xuxian Jiang )

24. Use Case - AnserverBot Trojan
RE Tools
Smali/Jasmin
Native Code
Dynamic
Bytecode Loading
Reflection
C&C ServerAggressive
Obfuscation

25. Use Case - AnserverBot Trojan
RE Tools
Smali/Jasmin
Native Code
Background Service
Dynamically Loaded

26. Use Case - AnserverBot Trojan
$ unzip anserverbot_sample.apk
$ cd assets
Payload A
Payload B

27. Use Case - APKTool
$ apktool d anserverbot_sample.apk

28. Use Case - AnserverBot Trojan - AndroidManifest
SUSPICIOUS

29. Use Case - AnserverBot Trojan - AndroidManifest
SUSPICIOUS

30. Use Case - AnserverBot Trojan - Payloads
Anservera.db and Anserverb.db are not database files.
Zip archives? => Android apps

31. Use Case - AnserverBot Trojan - Payloads
$ apktool d anservera.db

32. Use Case - AnserverBot Trojan – Dynamic Bytecode Loading
Payloads == Android code => Dynamic Bytecode loading!
Use ARES (Android Reverse Engineering Suite) or Androguard!

33. Use Case - AnserverBot Trojan - ARES
Payload A uses Dynamic Bytecode Loading AND Reflection

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. 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. 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. 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. 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. 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. 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. CONTENTS
> Motivation
> Android App Anatomy and Building Process
> Reverse Engineering
> Tools with Use Case
> Countermeasures

42. COUNTERMEASURES
How to protect your code once it is
distributed?
No silver bullet =(

43. COUNTERMEASURES
> Tamper detection
> Dynamic Bytecode Loading
> Obfuscation
> Anti-debugging
> Code/String Encryption
> Code Guards

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. 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. 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. 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. 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. 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. 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. COUNTERMEASURES – Obfuscation
> Tools: ProGuard/DexGuard, Arxan, DashO, Allatori, Stringer
> Attack: Decompile code and start with entry-point, refactor
through code, use Simplify

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. COUNTERMEASURES – Code/String Encryption

54. COUNTERMEASURES – Code/String Encryption
Packers
Stub Application
Hidden
Encrypted
Code
Stub Application
Decrypted
Code
Static Dynamic
Execution

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. 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. 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. YOUR
AVATAR
or YOUR
PHOTO
Dario Incalza
Application Security Engineering Analyst
LSEC – Leaders in Security
@h4oxer
Thank you!
droidcon Greece Thessaloniki