MobSecCon 2015 - Dynamic Analysis of Android Apps
- 1. Dynamic Analysis of Android Apps MobSecCon 2015 Erez Metula , Application Security Expert AppSec Labs (Chairman & Founder) ErezMetula@AppSec-Labs.com
- 2. About me Founder of AppSec Labs Application security expert Book author Managed Code Rootkits (Syngress) Speaker & Trainer Presented at BlackHat, Defcon, RSA, OWASP USA, OWASP IL, etc.. Secure Coding / Hacking trainer
- 3. AppSec Labs The leading Application Security Company A bunch of Application Security Experts Ninja Pentesters of Web & Mobile Apps Elite Trainers for Hacking & Secure coding courses
- 4. Agenda Why dynamic analysis? Memory dumps and analysis Smali debugging Setting breakpoints Native debugging with IDA (building signatures, types etc.) Runtime instrumentation and manipulation using ReFrameworker
- 5. Why dynamic analysis? Pentesing the app from the inside
- 6. Some examples real world scenarios encountered in the wild Requests to the server side are encrypted , signed, or just cannot be MiTMed for some reason Your proxy is useless. Dynamic values stored in memory - created while the app runs, received from network, etc. Decompiling is useless. The value is not in the code Strings are obfuscated Decompiling is hard The app is using some hard coded values such as URLS, encryption keys Patching is time consuming
- 7. Example requests with signed data Cannot manipulate with requests since they are signed
- 8. Example requests with encrypted data Cannot view/manipulate with requests since they contain encrypted data
- 9. Example obfuscated code/values Cannot read values from decompiled code since it is obfuscated
- 10. What to do? We must work from the inside Lets start with direct memory analysis Exposure of Code sections Sensitive data application data, passwords, encryption keys, network traffic, calculations, etc. Interactions with OS files, processes, etc.
- 11. Memory Analysis Eclipses MAT (Memory Analyzer Tool) Dump the applications current memory to disk Go to the DDMS Perspective, select the app and click Dump HPROF file
- 12. Query
- 13. Debugging Debugging allows us to analyze the app in real time Setting breakpoints Bypassing restrictions Jump into specific code sections Expose secrets from memory
- 14. Debugging With Source Debugging with the source is easy Just load the project in eclipse Place your breakpoint And click debug
- 15. Debugging Without Source (smali debugging) Most often you will not have the source Extracting the java code using dex2jar and creating an eclipse project is a bit tricky Rebuilding the project dependencies Decompiled code not always recompiles Alternatively, we can remote debug smali code
- 16. Major Steps Decode apk in debug (-d) mode: apktool d -d app.apk out Make it debuggable at the AndroidManifest.xml <application> tag <application . android:debuggable="true > Build new apk in debug (-d) mode: apktool b -d out Sign, install and run new apk signapk input.apk
- 17. Major Steps - Continued create Netbeans project add new Java Project with Existing Sources, select "out" directory as project root and "smali" subdirectory as sources dir. Find application port using DDMS it should be something like "86xx / 8700". Attached debugger in Netbeans Debug -> Attach Debugger -> select JPDA and set Port to 8700 (or whatever you saw in previous step). Set breakpoint. NOTE Officially, not all versions works, you need to use: netbeans 6.8 and apktool 1.4.1 Currently, you can also use NetBeans 7.2 with Apktool v2.0.0-Beta9
- 19. Tip - Wait for Debugger Programmatically by calling android.os.Debug.waitForDebugger() or boolean debuggerAttached = false; while(!debuggerAttached ) { ; } Another option DEV tools
- 20. JNI Debugging Suppose our target code is inside native .so files. We can use IDA to analyze it, and GDB to remotely debug it
- 21. Using IDA You can use existing static binary analysis (such IDA) to better understand the code It will give you the idea where to start, where to set breakpoints, etc.
- 22. JNI Debugging - Main Steps Find the process id, attach to it and create a listener port inside the device. Then remotely debug the app ps gdbserver :5050 --attach 1234 //pid=1234, port=5050 adb forward tcp:5050 tcp:5050 ndk-gdb target remote :5050 Then use regular GDB commands such as break, continue, finish, etc.
- 23. The ReFrameworker Platform Changing App Behavior Without Patching Any Code Runtime manipulation framework by AppSec Labs Integrated as part of AppUse Released at BlackHat USA 2013 Presented at OWASP IL 2013 look for the slides from last year for more info!!
- 24. How it Works The Android runtime was compiled with many hooks placed into key placed inside its code. The hooks look for a file called "Reframeworker.xml", located inside /data/system. So each time an application is executed, whenever a hooked runtime method is called, it loads the ReFrameworker configuration along with the contained rules ("items") and acts accordingly.
- 26. Enabling / Disabling ReFrameworker Replacing the original device jars with our modified version
- 27. DEMO ReFrameworker (if time permits)
- 28. Summary Runtime analysis provide us with the means to observe the behavior of an app during its execution It allows us to inspect issues such as communication, memory, file access, etc. We can detect problems that are hard to see using just static methods ReFreameworker is a great platform for that
- 29. QUESTIONS ?
- 30. THANK YOU ! Erez Metula , Application Security Expert AppSec Labs (Founder) ErezMetula@AppSec-Labs.com and last thing: were hiring !!!