1. REVERSE ENGINEERING, PENTESTING
AND HARDENING OF ANDROID APPS
Droidcon IT Torino 2014
!
Marco Grassi
@marcograss
-
Mobile Security Analyst @ viaForensics
1
2. $ whoami
• RD Team Member @ viaForensics
• Developer background (both Android
and iOS)
• Part of my job is to attack and break
mobile apps
2
3. 3
APK
Black Box Approach
=
We can use the app,
Dynamic Analysis,
Inspection
+
Reverse Engineering,
(Mainly) Static Analysis
4. AGENDA
• Reverse Engineering and Obfuscation
• Tampering Detection
• Logging
• File Storage
• Secure Network Communications
• IPC Attack Surface
• RAM memory attacks
• More Advanced Material : Runtime Manipulation
• Extra: Creating Cheats for Android Games : )
4
REAL WORLD EXAMPLES
6. PULLING THE APK FROM THE DEVICE
• Often the APKs are downloaded from Google Play on the device, how can we
extract them? Some solutions:
1. adb backup -apk com.mypackage (Works on Android 4.0 and newer)
2. Use a backup application (ASTRO File manager, Titanium Backup…)
3. adb shell , cd /data/app/, find your apk, then you can pull it with adb pull /data/app/
mypackage.apk (requires a adb root shell on the device)
6
7. REVERSE ENGINEERING
FREE TOOLS
• apktool and smali/baksmali
It will provide us a disassembled
representation of the Dalvik bytecode,
so sort “low level”, with registers, but
very understandable because of
bytecode metadata. Very useful to disable
tampering protections, the code can be
modified and the application can be
recompiled and resigned.
7
9. REVERSE ENGINEERING
FREE TOOLS
• dex2jar + Java decompiler (jd-gui, jad …)
dex2jar will convert the .dex file to a .jar
containing Java code
We can then use the freely available Java
decompilers and obtain back a Java
representation of the code.
Very readable if no obfuscation is in
place.
9
11. REVERSE ENGINEERING
PRO TOOLS
• JEB Decompiler
Renaming feature, very handy with
obfuscated applications
Python APIs
Native Dalvik decompiler, it does not
pass through Java byte code,
decompilation is usually much better
11
12. REVERSE ENGINEERING
PRO TOOLS
• IDA + Hex Rays Decompiler
De facto the best interactive disassembler
and decompiler on the market.
Impressive set of APIs, you can write
modules or scripts for everything.
12
13. REVERSE ENGINEERING
PRO TOOLS
• Hopper Disassembler
Very nice disassembler and decompiler
with a killer price.
13
14. OBFUSCATION
PROGUARD
• Free
• Integrated into the build environment
• NOT Android specific
• http://developer.android.com/tools/
help/proguard.html
14
16. OBFUSCATION
DEXGUARD
• Commercial product from ProGuard
author.
• Android specific
• Native support to string and code
encryption and tamper detection
• Very easy to use, with a config file like
ProGuard
16
18. TAMPERING DETECTION
• Check at runtime if the application has been modified in any way or if the signature
is changed.
• It can be done with the PackageManager class.
• Do the checks in multiple code points and use obfuscation, to avoid that it can be easily
bypassed.
• If your app ships only through Google Play, check with the APIs that it has been installed from
Google Play and not from Unknown Sources.
• If something is wrong, close the application without leaking informations where the protection
code is, to make attacker’s life harder.
18
19. DEFEATING TAMPERING DETECTION
WHY OBFUSCATION IS FUNDAMENTAL
Why spend hours on implementing if our application has been modified, if there is a single point
of failure?
!
If the attacker can easily find the code, it can modify the application and disable it.
19
20. LOGGING
• Remove Logcat logging from your production builds.
• It can be done with few lines in Proguard and Dexguard, they
remove all the calls to Log.d, Log.e etc in the build process
• It’s very easy for third party malware or an attacker to access the
Logs on Android.
20
21. FILE STORAGE
EXTERNAL STORAGE
• Try to avoid storing your
data in the shared storage,
almost any application can
read it. (In 4.4 a small protection at
permission level was added
android.permission.READ_EXTERNAL
_STORAGE, usually users does not check
permissions too much anyway… Don’t rely
on this.)
My Personal Data stored in a Evernote Note,
publicly readable by anyone.
21
CASE STUDY
22. FILE STORAGE
PRIVATE APP FOLDER
• Encrypt your preferences/files
• With root access they can be modified, avoid store sensitive data at all if possible
• With a backup, they can be retrieved from the device usually
• The private folder can be found on the device at path /data/data/yourpackage
That’s right.. It’s my User and my 36 character Password in PLAIN TEXT
22
CASE STUDY
23. FILE STORAGE
SQLITE DATABASES
shell@hammerhead:/ $ pm list packages | grep easy
package:com.handyapps.easymoney
shell@hammerhead:/ $ exit
$ adb backup -apk com.handyapps.easymoney
unpack the backup with
https://github.com/nelenkov/android-backup-extractor
PASSCODE IN PLAIN TEXT RETRIEVED.
23
FAIL!
CASE STUDY
24. SQLCIPHER
Very easy to use encrypted SQLite database.
Don’t store the key with the safe.
The user must provide the password to access the content if possible.
http://sqlcipher.net/sqlcipher-for-android/
24
25. #1 RULE: YOU DO
NOT IMPLEMENT
YOUR OWN
CRYPTOGRAPHY
#2 Rule: You do NOT implement your
own Cryptography
25
26. SECURE NETWORK COMMUNICATIONS
• It’s your responsibility to protect data in transit!
• Don’t transmit sensitive information without SSL/TLS
• Implement if possibile Certificate Pinning, in this way your
communications will be more resistant to MITM attacks, for example
if a malicious certificate is pushed into the device, or if an attacker
can impersonate your web service with a trusted certificate.
26
27. IPC ATTACK SURFACE
THE ANDROID MANIFEST
• Avoid the flag android:debuggable=true in production, an attacker can attach with a
debugger and execute arbitrary code in your app.
• Double check your exported components. Export a component to other processes
only if it’s strictly necessary and at least protect the component with a permission.
Android has some permissive defaults, some components are exported even if
they are not declared exported=true, check the documentation.
• If you export a content provider or another component that grants access to data
and accepts untrusted output, be careful on the input to avoid sql injections and path
traversal attacks.
27
28. IPC ATTACK SURFACE
EXAMPLE: SCREEN BYPASS
28
CASE STUDY
McAfee Antivirus Security
!
Now patched
It was possible to bypass the activation
and use for free some functionalities.
!
$ am start -a
android.intent.action.MAIN -n
com.wsandroid.suite/
com.mcafee.main.MfeMain
!
Credits: Sebastián Guerrero, @0xroot
29. 1PASSWORD READER
• Password wallet application for Android, a
companion application of the Mac/Windows
client, to be able to share our passwords
between our PC and the mobile device,
leveraging Dropbox or the Shared Storage.
29
CASE STUDY
30. BE CAREFUL WITH BROADCASTED
INTENTS
Vulnerable unprotected Broadcast Receiver to make the app timeout, with
a Broadcasted Intent (Dangerous!)
30
CASE STUDY
32. RESULTS
The Malware catch the Broadcast Intent before of the wallet. It
suppress it, so the Wallet never get the Intent and never go to
timeout its session.
!
What we learned: The system often is not trusted when doing IPC
with Intents, and in any case we must protect the exposed parts of our
application, auditing and remediating.
32
CASE STUDY
33. RAM MEMORY ATTACKS
• An attacker can retrieve and
inspect the ram memory used
by our application and search for
sensitive informations.
• Avoid storing such sensitive
informations inside instance or
static variables.
33
34. RAM MEMORY ATTACKS
• An easiest way to get an incomplete
(VM only) chunk of live memory from
our application is to use the “Dump
HPROF” functionality in the monitor
tool, with a debuggable application or
a device with the flag
ro.debuggable=1
34
36. RUNTIME MANIPULATION
Why modify the code of the application
recompiling it when we can modify the
code at runtime, without alerting the
basic tampering detection?
36
37. RUNTIME MANIPULATION
We can change the behaviour of the applications and the system
without touching any APK and we can enable/disable plugins with
ease.
!
We must have a rooted phone and install a framework that will
modify some low level components of the Android OS, to make
our life easier.
37
38. MOST POPULAR FRAMEWORKS
• Cydia Substrate
• Xposed Framework
38
http://www.cydiasubstrate.com/
http://repo.xposed.info/
39. HOW CAN WE DEVELOP A PLUGIN AND
WHAT WE CAN DO WITH IT?
39
40. 1PASSWORD READER
• Password wallet application for Android, a
companion application of the Mac/Windows
client, to be able to share our passwords
between our PC and the mobile device,
leveraging Dropbox or the Shared Storage.
40
CASE STUDY
41. 1PASSWORD: WHY SHARED STORAGE
AND DROPBOX?
• This choices are forced for technical limitation in the sharing process
between the PC and the device.
• Without root permissions, the user can only write in the shared
folder, or the application can use third party services, such file sharing
API by Dropbox, to share the wallet file.
41
CASE STUDY
42. FIRST LOOK
• The 1Password wallet is totally unobfuscated, so an attacker can
easily understand the logic of the application and the weak points.
• First weak spot: LOGS, the application disabled in productions the
logging of the user credentials and other internal information to the
Logcat, but the logs are only disabled, the code that logs at the critical
points (even the user password) it’s in there.
42
CASE STUDY
48. AGIMAT
• Simple cheat engine/app for Android
using runtime manipulation
• When more games are supported and
if there is interest, it will be open
sourced (no time)
48