droidcon Greece Thessaloniki 10-12 September 2015
Reverse Engineering in Android Countermeasures and Tools
$ whoami > Dario Incalza (@h4oxer) > Application Security Engineering Analyst > Android Developer
CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
MOTIVATION > Good Guys: > Understand Malware > Security Research > Bad Guys: > Piracy > Steal Intellectual Property > Introduce backdoors
IS IT LEGAL? > 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 ;-)
CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
Android Application Anatomy.zip file Android Package (.apk) Dalvik byte code uncompiled resources classes.dex resources. arsc Compiled resources Third-party.so libraries AndroidManifest.xml Native Libraries Binary version of AndroidManifest.xml
Android Build Process
Application Execution > 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 JIT AOT
CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
Reverse Engineering Dalvik ByteCode APK RE Tools Java Code Smali/Jasmin Native Code
Reverse Engineering Dalvik ByteCode Dalvik ByteCode Java Code RE Tools Smali/Jasmin
Reverse Engineering Smali Dalvik ByteCode Java Code RE Tools Smali/Jasmin
Reverse Engineering To which format do I RE the.apk? > Depends on what you want to achieve > Understanding internal mechanisms => Java Code > Instrumenting RE Tools apps => Dalvik/Smali Bytecode/Jasmin > Native libraries => RE the.so library to native code Usually a combination of all Smali/Jasmin Native Code
Reverse Engineering RE Java Code Information < Original Java Code Information Reason: Information RE loss Tools when building classes.dex from.class Smali/Jasmin Consequence: Impossible to rebuild RE Java Code, use Dalvik Byte Code format instead Native Code
Reverse Engineering How does a regular RE process RE Tools looks like? Smali/Jasmin Native Code
Reverse Engineering First Step: Objectives 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, RE if so, Tools why is it using reflection? Is it using dynamic bytecode loading, if so why is it using it? Is it using obfuscation? Smali/Jasmin Is it malware? Native Code
Reverse Engineering Second Step: Info gathering > Don t jump to looking at code in the wild! > app name, icon, activities, receivers, services, permissions, intents (AndroidManifest.xml) > strings.xml RE Tools > native.so libraries Smali/Jasmin > signature of the app Native Code
Reverse Engineering Third Step: Hacking Time Now experience comes into play > decompile classes.dex or.so libraries > Find entry-points RE Tools > Search for dynamic bytecode Smali/Jasmin loading, permission usage, reflection, crypto code Native Code
CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
Use Case AnserverBot Trojan RE Tools (August 2011 - Yajin Zhou, Xuxian Jiang ) Smali/Jasmin Native Code
Use Case - AnserverBot Trojan Dynamic Bytecode Loading Reflection RE Tools Smali/Jasmin Aggressive Obfuscation Native Code C&C Server
Use Case - AnserverBot Trojan Background Service RE Tools Smali/Jasmin Native Code Dynamically Loaded
Use Case - AnserverBot Trojan $ unzip anserverbot_sample.apk $ cd assets Payload A Payload B
Use Case - APKTool $ apktool d anserverbot_sample.apk
Use Case - AnserverBot Trojan - AndroidManifest SUSPICIOUS
Use Case - AnserverBot Trojan - AndroidManifest SUSPICIOUS
Use Case - AnserverBot Trojan - Payloads Anservera.db and Anserverb.db are not database files. Zip archives? => Android apps
Use Case - AnserverBot Trojan - Payloads $ apktool d anservera.db
Use Case - AnserverBot Trojan Dynamic Bytecode Loading Payloads == Android code => Dynamic Bytecode loading! Use ARES (Android Reverse Engineering Suite) or Androguard!
Use Case - AnserverBot Trojan - ARES Payload A uses Dynamic Bytecode Loading AND Reflection
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()
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
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
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?
Use Case Decompile with Simplify Smali Files Classes.dex JAR Smali from Simplify dex2jar JAD APK Eliminates useless code, encryption, makes code more readable
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
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.
CONTENTS > Motivation > Android App Anatomy and Building Process > Reverse Engineering > Tools with Use Case > Countermeasures
COUNTERMEASURES How to protect your code once it is distributed? No silver bullet =(
COUNTERMEASURES > Tamper detection > Dynamic Bytecode Loading > Obfuscation > Anti-debugging > Code/String Encryption > Code Guards
COUNTERMEASURES TAMPER DETECTION > Detect app modification/repacking > APKTool makes it easy to repack > What if we could detect rebuild/recompilation/repackaging? Source: BlueBox Security
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)
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.
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
COUNTERMEASURES TAMPER DETECTION <application> < android.name= detect.class > <activity android:name= "com.example.manifestexample.mainactivity"> <intent filter> <action android:name= "android.intent.action.main" / > </intent filter > </activity> </application>
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
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
COUNTERMEASURES Obfuscation > Tools: ProGuard/DexGuard, Arxan, DashO, Allatori, Stringer > Attack: Decompile code and start with entry-point, refactor through code, use Simplify
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
COUNTERMEASURES Code/String Encryption
COUNTERMEASURES Code/String Encryption Packers Static Dynamic Stub Application Execution Stub Application Hidden Encrypted Code Decrypted Code
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
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
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
Thank you! droidcon Greece Thessaloniki YOUR AVATAR or YOUR PHOTO Dario Incalza Application Security Engineering Analyst LSEC Leaders in Security @h4oxer