The document summarizes an Android security workshop that took place on February 24th, 2016 in Poland. The workshop included sessions on Android fundamentals, application component security, and the OWASP top 10 mobile risks. It also covered reverse engineering and malware analysis. The document provides an agenda and summaries of the topics discussed in each session, including details on Android architecture, security features in Android 6.0, application permissions and components, and common mobile risks. It aims to provide attendees with a basic understanding of Android security concepts and methodologies for analyzing mobile applications for security issues.

1. Android security workshop
OWASP Poland
24.02.2016

2. Agenda
 Android fundamentals
 Application components security
 Coffee break (free cookies )
 OWASP top 10 mobile risks
 Reverse engineering & malware analysis

3. Android fundamentals
Andrii Sygida
OWASP Poland
24.02.2016

4. Agenda
• Android Architecture
• Android security fundamentals
• Android 6.0 security release
• Google security features

5. Intro
• Android is the world's most popular mobile platform.
Features:
• Multi-tasking
• Widgets
• Notifications
• Voice Typing and Actions
• Photos and video
• Most widely used smartphone OS
• Phones, tablets, Google TV and more

6. Stats
• There are 1.2 billion mobile users. By 2018 that number with
be 5 billion.
• Mobile adoption is growing 8x faster than traditional web
applications.
• Mobile payments will exceed $90 Billion by 2017
Bugcrowd Cybersecurity Research 2015

7. Android Architecture

8. Linux Kernel
• The architecture is based on the Linux ( started from 2.6)
kernel.
• This layer is core of android architecture. It provides service
like power management, memory management, security etc.
• It helps in software or hardware binding for better
communication.

9. Libraries
• The next layer is the Android’s native libraries.
• It is this layer that enables the device to handle different types
of data.
• The WebKit library is responsible for browser support, SQLite is
for database, FreeType for font support, Media for playing and
recording audio and video formats

10. Android Runtime
• Core libraries
• Dalvik Virtual Machine
• DVM vs JVM Differences
• ART

11. Dalvik VM
• The software that runs the apps on Android devices
• It's fast, even on weak CPUs
• it will run on systems with little memory
• it will run in an energy-efficient way
• Provides application portability and runtime consistency
• Runs optimized file format (.dex) and Dalvik bytecode
• Java .class / .jar files converted to .dex at build time

12. ART VS DVM
• Android 4.4 – Experimental. From android 5.0 - Default
• Ahead-of-time (AOT) compilation
• Improved garbage collection
• Improved diagnostic detail in
exceptions and crash reports

13. Application Framework
Activity Manager: Manages the activity life cycle of applications
Content Providers: Manage the data sharing between applications
Telephony Manager: Manages all voice calls.
Location Manager: Location management, using GPS or cell tower
Resource Manager: Manage the various types of resources we use in our
Application

14. Application Layer
• SMS client app
• Dialer
• Web browser
• Contact manager

15. APK how it’s works

16. Android Application Security
• Android sandbox
• Permission labels defined in AndroidManifest.xml
• Signature
• Install time security decisions
• Android 6.0 Security release

17. Android 6.0
• Runtime Permissions
• Verified Boot
• Hardware-Isolated Security
• Fingerprints
• SD Card Adoption
• Clear Text Traffic
• System Hardening
• USB Access Control

18. Defense layers

19. Google Play
1 2 3 4 5
Require and
validate
Developer
information
Review
Applications
before
distribution
Permanently
stop distribution
Reduce attacker
flexibility
Remove
applications
after installation

20. Apps from Unknown Sources
By default, only Google Play and
other pre-installed app stores are
allowed to install apps
The vast majority of installs come from
Google Play

21. Verify Apps
Apps are verified prior to install
Warn for or block Potentially Harmful Applications
Over 10 million installs verified every day

22. Verifying is on and visible when need

23. Core security features to build secure applicaton
• The Android Application Sandbox.
• An application framework with robust implementations of common
security functionality such as cryptography, permissions.
• An encrypted file system that can be enabled to protect data on lost
or stolen devices.
• User-granted permissions to restrict access to system features and
user data.
• Application-defined permissions to control application data on a
per-app basis.

24. Thank you 
Any questions?

25. Links
• http://developer.android.com/about/dashboards/index.html
• https://docs.google.com/presentation/d/1YDYUrD22Xq12nKkhBfwoJBfw2Q-
OReMr0BrDfHyfyPw/pub?start=false&loop=false&delayms=3000&slide=id.g1202bd8e5_0193
• http://www.cubrid.org/blog/dev-platform/android-at-a-glance/
• http://news.softpedia.com/news/Google-Introduces-Android-L-Developer-Preview-Material-Design-ART-64-Bit-Support-Volta-448367.shtml
• http://developer.android.com/tools/building/index.html
• http://android-anything.diandian.com/post/2011-09-28/5377936
• http://www.vogella.com/tutorials/Android/article.html#androiddevelopment_art
• https://source.android.com/devices/tech/dalvik/index.html
• https://en.wikipedia.org/wiki/Android_Runtime
• https://source.android.com/devices/tech/dalvik/gc-debug.html
• https://source.android.com/security/overview/app-security.html
• http://www.javatpoint.com/internal-details-of-hello-android-example
• https://decompileandsecureapk.wordpress.com/2014/05/10/decompile-and-secure-android-apk/
• http://developer.android.com/tools/debugging/debugging-memory.html#LogMessages
• https://source.android.com/devices/
• http://www.cubrid.org/blog/dev-platform/android-at-a-glance/
• http://developer.android.com/training/articles/security-tips.html
• https://developer.android.com/guide/topics/manifest/manifest-intro.html
• https://source.android.com/security/overview/app-security.html
• http://www.compiletimeerror.com/2012/12/blog-post.html#.VsReZ_krKM-
• http://www.slideshare.net/Sperasoft/sperasoft-talks-android-security-threats?qid=d4d0db3a-0451-4150-95e0-
dcd364cc95b4&v=qf1&b=&from_search=8
• http://www.eazytutz.com/android/android-architecture/
• http://www.tutorialspoint.com/android/android_architecture.htm

26. Application Components Security
Alexander Antukh
OWASP Poland
24.02.2016

27. Android Application Security
Often the app contains some sensitive data:
• Passwords
• Authentication tokens
• Contacts
• Communication records
• IP addresses or domain names to sensitive
services

28. Android Application Security
Global problems in securing the applications:
• How sensitive data is stored
– Isolation
– Privilege separation
• How sensitive data is transmitted
– Extra-device communication
– Inter-application communication
– Inter-component communication

29. Android Application Components
Activities Services
Content
providers
Broadcast
receivers

30. Android Application Components
AndroidManifest.xml: defines in which way the app
works and what kind of interaction between
components and outer world is possible.
Permissions are set there, too.
• Activities – <activity>
• Services – <service>
• Content providers – <provider>
• Broadcast receivers – <receiver>

31. Android Manifest
Sample manifest file:
Note the following:
• Permissions
<uses-permission android:name="string"/>
<permission android:protectionLevel="…" />
• Components and their attributes

32. Android Manifest
Protection levels:
• dangerous – increased risk (directly affect users)
• normal – minimal risk (default value)
• signature – same certificate
• signatureOrSystem – same certificate || app in
Android system image

33. Android Manifest
• debuggable
• enabled
• exported
• permission
Activities Services
Content
providers
Broadcast
receivers
Example components attributes:

34. Intents
An intent is a defined object used for messaging that is created
and communicated to an intended application component. It
includes all relevant information about calling application,
desired application component and request actions/data
Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setData(Uri.parse("http://www.google.com"));
String pack = "com.android.browser";
ComponentName comp = new ComponentName(pack, pack + ".BrowserActivity");
intent.setComponent(comp);
startActivity(intent);

35. Drozer
Open source tool to interact with other
applications through IPC - leading security
assessment framework for Android.
Manual on installation and usage

36. Drozer
The best thing about Drozer: you don’t need to
write your apps to interact with other apps :)
dz> run app.activity.start
--action android.intent.action.VIEW
--data-uri http://www.google.com
--component com.android.browser
com.android.browser.BrowserActivity

37. Drozer
Is installed in a default package of AppUse with
adb, so enough just „click-and-play”

38. Activity components
An Activity provides a screen with which users
can interact in order to do something. Users can
perform operations such as making a call,
sending an SMS, etc.
Example: login screen of your Facebook app.
Activities

39. Activity components attacks
• If an activity can be triggered by other apps
(by an attacker), it can be abused!
• Launching by intents, it’s possible to achieve
the following:
– Modify data in background
– Tricking the user
– Leaking sensitive information
Activities

40. Activity components attacks
• General hijacking scheme:
• Results of an attack:
– Malicious Activity could read the data in the Intent and then
immediately relay it to a legitimate one
– Spoofing the expected Activity’s user interface to steal user-supplied
data (phishing)
Activities

41. Activity components attacks Activities
• List and launch exported activities
dz> run app.activity.info -a com.mwr.example.sieve
Package: com.mwr.example.sieve
com.mwr.example.sieve.FileSelectActivity
com.mwr.example.sieve.MainLoginActivity
com.mwr.example.sieve.PWList
dz> run app.activity.start --component com.mwr.example.sieve
com.mwr.example.sieve.PWList

42. Activity components demo Activities

43. Services
A Service can perform long-running operations in
the background and does not provide a user
interface. Other components can bind to a Service,
which lets the binder invoke methods that are
declared in the target Service’s interface. Intents are
used to start and bind to Services
Example: playing music or downloading a file.
Services

44. Services attacks
Although generally don’t seem dangerous, they
could potentially perform sensitive operations.
To attack a service one need interaction (it must
be exported or respond/accept input from
message formats like intents, files, or the
network stack)
Services

45. Services attacks
Typical attacks: Denial of Service and
Information Leakage
• Find exported services
• Launch them one-by-one with logcat to check
for sensitive info
• Fire off intents and wait for it!
Services

46. Content providers
A content provider presents data to external
applications as one or more tables. In other words,
content providers can be treated as interfaces that
connect data in one process with code running in
another process.
Example: using content providers, any app can read
SMS from inbuilt SMS app’s repository in our
device.
Content
providers

47. Content providers
• What info can they hold?
– User’s phone numbers
– Passwords
– SMS
• And one of the main problems are again
permissions!
run app.provider.info --permission null
Content
providers

48. Content providers attacks
• Unrestricted access to app database
– Just query it! *
– run app.provider.query content://settings/secure
• SQL injection
• Path traversal
* Other attack vectors on auth might include altering data e.g. by using
app.provider.insert command
Content
providers
dz> run scanner.provider.injection -a com.mwr.example.sieve

49. Content providers attacks
• Unrestricted access to app database
Content
providers
dz> run scanner.provider.finduris -a com.mwr.example.sieve
...
Accessible content URIs:
content://com.mwr.example.sieve.DBContentProvider/Keys/
content://com.mwr.example.sieve.DBContentProvider/Passwords
content://com.mwr.example.sieve.DBContentProvider/Passwords/
dz> run app.provider.query
content://com.mwr.example.sieve.DBContentProvider/Passwords/ --vertical

50. Content providers attacks
• SQL injection
Content
providers
dz> run app.provider.query
content://com.mwr.example.sieve.DBContentProvider/Passwords/ --selection "'"
unrecognized token: "')" (code 1): , while compiling: SELECT * FROM Passwords
WHERE (')
dz> run app.provider.query
content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "*
FROM Key;--"
| Password | pin |
| thisismypassword | 9876 |

51. Content providers attacks
• Path traversal
Content
providers
One interesting real-life example: http://blog.seguesec.com/2012/09/path-traversal-vulnerability-on-shazam-android-application/
dz> run app.provider.read
content://com.mwr.example.sieve.FileBackupProvider/etc/hosts
127.0.0.1 localhost
dz> run app.provider.download
content://com.mwr.example.sieve.FileBackupProvider/data/data/com.mwr.e
xample.sie ve/databases/database.db /home/user/database.db
Written 24576 bytes

52. Content providers demo Content
providers

53. Broadcast receivers
A broadcast receiver is a component that
responds to system-wide broadcast
announcements such as Battery Low, boot
completed, headset plug etc. Though most of
the broadcast receivers are originated by the
system, applications can also announce
broadcasts.
Broadcast
receivers

54. Broadcast receivers
• If receiver accepts broadcasts from untrusted
sources, app is at risk
Broadcast
receivers

55. Broadcast receivers attacks
Typical fail: authorization!
• Enumerate receivers
• Determine how the receiver handles the
action
• Send intent and enjoy
Broadcast
receivers

56. Broadcast receivers attacks
<receiver
android:name=".broadcastreceivers.SendSMSNowReceiver”
android:label="Send SMS" >
<intent-filter>
<action android:name="org.owasp.goatdroid.fourgoats.SOCIAL_SMS" />
</intent-filter>
</receiver>
…
<uses-permission android:name="android.permission.SEND_SMS" />
Sample manifest from GoatDroid:
Broadcast
receivers

57. Broadcast receivers attacks
public void onReceive(Context arg0, Intent arg1) {
context = arg0;
SmsManager sms = SmsManager.getDefault();
Bundle bundle = arg1.getExtras();
sms.sendTextMessage(bundle.getString("phoneNumber"), null,
bundle.getString("message"), null, null);
Utils.makeToast(context, Constants.TEXT_MESSAGE_SENT,
Toast.LENGTH_LONG);
}
The following is the code that determines how the receiver
handles the org.owasp.goatdroid.fourgoats.SOCIAL_SMS
actions:
Broadcast
receivers

58. Broadcast receivers attacks
run app.broadcast.send
--action
org.owasp.goatdroid.fourgoats.SOCIAL_SMS
--component org.owasp.goatdroid.fourgoats
org.owasp.goatdroid.fourgoats.broadcastreceive
rs.SendSMSNowReceiver
--extra string phoneNumber 1234567890
--extra string message PWNED
Broadcast
receivers

59. General defenses for App Components
Applies for all abovementioned items:
• Setting "android:exported" attribute to "false"
(only this user ID as the current app will be
able to access the activity)
• Limiting access with custom permissions for
an activity (RECEIVE_SMS and others)

60. References
• http://developer.android.com/guide/components/index.html
• http://developer.android.com/guide/topics/manifest/manifest-intro.html
• http://resources.infosecinstitute.com/android-hacking-security-part-1-exploiting-securing-application-
components/
• http://resources.infosecinstitute.com/android-hacking-security-part-2-content-provider-leakage/
• http://resources.infosecinstitute.com/android-hacking-security-part-3-exploiting-broadcast-receivers/
• http://yinzhicao.org/courses/f15/cse343443/slides/mobilesecurity.pdf
• https://www.safaribooksonline.com/library/view/android-security-cookbook
• https://www.mwrinfosecurity.com/system/assets/937/original/mwri_drozer-user-guide_2015-03-23.pdf
• https://manifestsecurity.com/android-application-security-part-5/
• https://manifestsecurity.com/android-application-security-part-8/
• https://www.eecs.berkeley.edu/~daw/papers/intents-mobisys11.pdf
• http://blog.seguesec.com/2012/09/path-traversal-vulnerability-on-shazam-android-application/
• https://github.com/tanprathan/MobileApp-Pentest-Cheatsheet#android-application-penetration-testing

61. Thank you!
• For additional questions or just to stay in
touch: @c0rdis.

62. OWASP top 10 mobile risks
Pawel Rzepa
OWASP Poland
24.02.2016

63. Important notes
• The goal of this presentation is to provide you a basic
knowledge about mobile risks and easy methodology
to find those risks in your applications.
• If you want to add anything important/interesting
and related to the topic – feel free to interrupt me ;).

64. What are we going to talk about…

65. Before we start… the threat model

66. M2 - Insecure data storage

67. Insecure data storage – what it is?
• Simple words definition: valuable pieces of
data (e.g. passwords, cookies, personal
information) are stored in the data-stores on
the device in insecure (plain text or reversable
encoding) format.

68. Insecure data storage – what to look for?
• Look for any sensitive information in:
– SQLite databases (local)
– XML Data Stores
– Plain text configuration files
– Cookie stores
– SD Card

69. Insecure data storage – how to find?
• Install and run application for some time
• Monitor changes in /sdcard before and after
installing an application
• Analyze package files on different stages:
adb pull /data/data/<apk_package_name>

70. Insecure data storage - demo

71. Insecure data storage – real example
• Outlook stored all attachements as
unencrypted and world readable files on
external storage.

72. Insecure data storage - mitigations
• Don’t store data unless it’s absolutely
necessarry.
• Use encryption for local storage (use method
setStorageEncryption).
• For databases consider using SQLcipher for
Sqlite data encryption.
• Ensure any shared preferences properties are
NOT MODE_WORLD_READABLE.

73. M3 - Insufficient transport layer
protection

74. Insufficient transport layer protection
– what it is?
• Simple words definition: application does NOT
implement TLS or it does incorrectly.

75. What do you mean „incorrectly”?
• Insecure implementations are:
– Using known weak ciphers / version (e.g.
SSLv2/SSLv3, RC4)
– Securing only part of the communication (e.g. only
authentication)
– Lack of certificate inspection

76. Certificate inspection in web
applications – chain of trust.
• In web applications the validation of certificate is on
the side of a browser.
• It is done by a „chain of trust”.
• But how a mobile app can know if it is
communicating with a proper server?

77. Cert Pinning - theory
• Embedded in source code expected X509
certificate or public key.
if (presented_cert == pinned_cert)
Start_connection();
else
Drop_connection();

78. Cert Pinning - reality
• Guys from Leibniz Universität Hannover tested
100 apps and…
• 21 apps trust all certificates
• 20 apps accept all hostnames
• And in the end they asked developers why it
happened…
More: https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf

79. Insufficient transport layer protection-
how to find?
• Passive analysis with Wireshark/Burp (to
check if all traffic is encrypted)
• Use Mallodroid:
./mallodroid.py –f AppToCheck.apk –d ./javaout
• Look for end point implementation flaws using
SSLyze (or https://www.ssllabs.com/ssltest/
for public domain):
sslyze --regular www.example.com:443

80. Insufficient transport layer protection-
example

81. Insufficient transport layer protection-
few facts from reality
• According to the FireEye research from July 17
2014, among 1000 most-downloaded free
applications in the Google Play store:
Source: https://www.fireeye.com/blog/threat-research/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html

82. Insufficient transport layer protection-
mitigations
• Any sensitive data MUST be transfered over TLS
• How to do it properly? Follow the rules:
https://www.owasp.org/index.php/Transport_Layer_Protectio
n_Cheat_Sheet

83. M4 - Unintended data leakage

84. Unintended data leakage – what it is?
• Simple word definition: OS/frameworks puts
sensitive information in an insecure location in
the device.
• Important note: insecure data storage talks
about developer conscious efforts to store
data in insecure manner, while unintended
data leakage refers to OS/framework specific
quirks which can cause data leakages.

85. Unintended data leakage – common
leakage points
• URL Caching
• Copy/Paste buffer Caching
• Logging
• Analytics data sent to 3rd parties (e.g. ads
sending GPS location)

86. Unintended data leakage – how to
find?
• Extract data from leaking content providers using
Drozer:
dz> run app.provider.finduri <package_name>
• Use logcat to verify what is being logged using
ADB:
adb logcat [output filter]
• Use listener (Burp/Wireshark) to monitor what is
being sent to 3rd parties.
• Use Intent Sniffer to see if any confidential data is
sent via Intents.

87. Unintended data leakage - demo

88. Unintended data leakage - mitigations
• NEVER log any sensitive information (observe
what you’re storing in crashlogs).
• Disable copy/paste function for sensitive part
of the application.
• Disable debugging
(android:debuggable="false").

89. M5 - Poor Authorization and
Authentication

90. Poor Authorization and Authentication
– what is it?
• Simple words definition: if you’re able to
bypass authentication and/or laverage your
privileges then… your app has poor
authorization and/or authentication.

91. Poor Authorization and Authentication
– how to find?
• Try to bypass authentication by accessing
exported activities using Drozer:
dz> run app.activity.start –component <component_name>
• Intercept traffic with Burp and modify parameter
to login as other user/see unauthorized content
(e.g. by manipulating device ID).
• Test account lockout policy
• Test strong password policy

92. Poor Authorization and Authentication
- demo

93. Poor Authorization and Authentication
– real example
• A flaw in application can become an entry
point to compromise an operating system.
• For example a Viber app:
https://www.youtube.com/watch?time_continue=40&v=rScheIQDD0k

94. And always remember to…
• …stay reasonable when you’re going to follow
advices from the Internet…

95. Poor Authorization and Authentication
- mitigations
• Assume that client-side authorization and
authentication controls can be bypassed - they
must be re-enforced on the server-side whenever
possible!
• Persistent authentication (Remember Me)
functionality implemented within mobile
applications should never store a user’s
password on the device. It should be optional
and not be enabled by default.

96. M6 - Broken Cryptography

97. Broken Cryptography – what it is?
• Simple words definition: using insecure
implementation or implementing it in a
insecure way.
• Few reminders (yeah I know you know it…):
– encoding != encryption
– obfuscation != encryption

98. Broken Cryptography – how to find?
• Decompile the apk using dex2jar (or luyten for
more verbose result) and review jar file in JD-GUI.
• Look for decryption keys (in attacker-readable
folder or hardcoded within binary).
• Try to break encryption algorithm if an
application uses custom encryption.
• Look for usage of insecure and/or deprecated
algorithms (e.g. RC4, MD4/5, SHA1 etc.).

99. Broken Cryptography - example
• Encrypted db is definitely a good idea…

100. Broken Cryptography - example
• …but not when you’re hardcoding passwords
to decrypt it in code…

101. Broken Cryptography – real example
• NQ Vault

102. Broken Cryptography - mitigations
• Use known, strong cryptography
implementations.
• Do not hardcode keys/credentials/OAUTH
tokens.
• Do not store keys on a device. Use password
based encryption instead.

103. M7 - Client side injection

104. Client side injection – what it is?
• Simple words definition: malicious code can
be provided as an input and executed by the
application (on the client side).
• The malicious code can come from:
– Other application via intent/content provider
– Shared file
– Server response
– Third party website

105. Client side injection – what to inject?
• SQL injection to local db
• XSS/WebView injection
• Directory traversal
• Intent injection

106. A new Android’s toy – the Intents
• Android application can talk
(Inter-Process-
Communication) to any
other component (e.g.
other application, system
service, running new
activity etc.) via special
objects called Intents.
Intent i = new Intent(Intent.ACTION_VIEW,Uri.parse(„https://owasp.org”));
Intent i = new Intent(android.provider.MediaStore.Action_IMAGE_CAPTURE);

107. Client side injection – how to find?
• SQL injections:
dz> run scanner.provider.injection –a <package_name>
• Data path traversal
dz> run scanner.provider.traversal –a <package_name>
• Intent injections
dz> run app.package.manifest –a <package_name>
dz> run app.activity.info –a <package_name>
dz> run app.service.info --permission null –a <package_name>
dz> run intents.fuzzinozer --package_name <package_name> --
fuzzing_intent

108. Client side injection – real example
• The UniversalMDMClient (built-in application Samsung KNOX
– a security feature to seperate personal and professional
activities).
• Crafted URI with „smdm://” prefix allows for remote
installation of ANY application, while a user thinks he’s
installing an update for UniversalMDMClient.
• How it works in practice?
https://www.youtube.com/watch?time_continue=56&v=6O9OBmsv-CM

109. Client side injection - mitigations
• Always validate on a server side any user input!
• For internal communication use only explicit
Intents.
• Avoid using Intent-filter. Even if the Activity has
atribute „exported=false” another application can
define the same filter and a system displays a
dialog, so the user can pick which app to use.

110. M9 - Improper session handling

111. Improper session handling – what it is?
• Simple words definition: if your session token
can be guessed, retrieved by third party or
never expires then you have a problem.

112. Improper session handling – how to
find?
• Intercept requests with proxy (e.g. Burp) and
verify if:
– Verify if a session expires (copy a cookie and try to use
it after 30 minutes)
– Verify if a session is destroyed after authentication
state changes (e.g. switching from any logged in user
to another logged in user)
– Verify if you are able to guess any other session (e.g.
it’s easy to impersonate other user when application
uses device ID as a session token).

113. Improper session handling – few facts
from reality
• What we know is that „sessions have to expire”…
• …but how long should it REALLY last?
• According to experiment* the average application
session (counted from opening an app to closing
it) lasts… 71.56 seconds.
* - http://www.mendeley.com/research/falling-asleep-angry-birds-facebook-kindle-large-scale-study-mobile-application-usage/

114. Improper session handling -
mitigations
• Invalidate session on a server side.
• Set session expiration time adjusted to your
application.
• Destroy all unused session tokens.
• Use only high entropy, tested token
generation resources.

115. Thank you!
pawel.rzepa@outlook.com

116. References
• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
• https://github.com/ikust/hello-pinnedcerts
• http://www.exploresecurity.com/testing-for-cipher-suite-preference/
• http://resources.infosecinstitute.com/android-hacking-security-part-4-exploiting-unintended-data-leakage-side-channel-data-leakage/
• http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks
• https://manifestsecurity.com/android-application-security/
• https://mobilesecuritywiki.com/
• http://androidcracking.blogspot.de/2014/02/zerdeis-luyten-worthwhile-jd-gui.html
• https://www.acsac.org/2011/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=111&type=3&OPENCONF=54jm3hh7l
aelc19qq6ernql5m2
• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Mobile_Threat_Model
• https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Security_Testing
• https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf
• https://www.ssllabs.com/ssltest/
• http://www.slideshare.net/ibmsecurity/overtaking-firefox-profiles-vulnerabilities-in-firefox-for-android
• http://resources.infosecinstitute.com/cracking-nq-vault-step-by-step/
• http://www.slideshare.net/ibmsecurity/pinpointing-vulnerabilities-in-android-applications-like-finding-a-needle-in-a-haystack
• https://github.com/linkedin/qark
• https://www.mendeley.com/catalog/falling-asleep-angry-birds-facebook-kindle-large-scale-study-mobile-application-usage/
• http://blog.quarkslab.com/abusing-samsung-knox-to-remotely-install-a-malicious-application-story-of-a-half-patched-vulnerability.html
• http://www.bkav.com/top-news/-/view_content/content/46264/critical-flaw-in-viber-allows-full-access-to-android-smartphones-bypassing-lock-
screen
• http://thehackernews.com/2014/05/microsoft-outlook-app-for-android.html
• https://drive.google.com/file/d/0BxOPagp1jPHWVnlzWGNVbFBMTW8/view?pref=2&pli=1

117. Reverse Engineering &
Malware Analysis
Daniel Ramirez
OWASP Poland
24.02.2016

118. Anatomy of an apk

119. Getting our apk file
• From the phone
– APKOptic
– Astro File Manager
• Using ADB
• Use APKpure

120. Decompiling || Disassembling
• Decompiling:
– High Level – Java Code
• Disassembling:
– Low Level – Assembly Code
• Why Disassembling and not Decompiling?

121. Decompiling
DEX JAR JAVA
JAR DEXJAVA

122. Decompiling-Dex2Jar
• dex2jar
– Converts Dalvik bytecode (DEX) to java bytecode
(JAR)
– Allows to use any existing Java decompiler with
the resulting JAR file

123. Decompiling – Java Decompilers
• JD-GUI || Luyten
– Closed source Java decompiler
– Combined with dex2jar, you can use JD-GUI or
Luyten to decompile Android applications
• Both are Java decompilers but have different
OUTPUT!

124. JD-GUI

125. Luyten

127. Disassembling
DEX SMALI

128. Disassembling
• Apktool
– Open source Java tool for reverse-engineering
Android app
– Transform binary Dalvik byte code(dex) into Smali
source

129. Signing apk
• Using signapk.jar
java -jar signapk.jar certificate.pem key.pk8 your-
app.apk your-app-signed.apk
• Using AppUse

130. Demo Time

131. Demo Decompiling Luyten

132. Demo Modify Smali Files

133. Demo

134. Lack of binary protection
• At this point if you can read the source code of
the application, modify the behavior of the
application  doesn’t have enough
protection.

135. Techniques to mitigate the Lack of
Binary Protection

136. Verify Sign

137. Obfuscated
• Some obfuscation tool, allow to encrypt String
in source code.
– ProGuard(*)
– DexProtector
– DexGuard

138. Anti-Emulator

139. Debuggable

140. Demo Time #2

141. Demo

142. Demo Decompiling Luyten

143. Demo Modify Smali Files

144. Demo

145. Recap
• We’ve seen how it’s possible change the
behavior of an app by disassembling, modify
the smali code and recompiling the app
• Some techniques to “try” to prevent the lack
of binary protection

146. MALWARE

147. Malware Statistics #1

148. Malware Statistics #2

149. Malware #1-Flappy-bird
• Some application ask for permission that don’t
need.
• E.g: Game asking for send sms ??

150. Malware #1-Flappy-bird
• Some application ask for permission that don’t
need.
• E.g: Game asking for send sms ??

151. Malware #2-iMatch

152. Permissions Dangerous #1

153. Permissions Dangerous #2

154. Dendroid botnet
Botnet especially developed for attacking android user’s which has the
functionalities like
• Record call
• Block SMS
• Take video/photo
• Send text
• Send contacts
• Get user account
• Call Number
• Update App
• Delete files
• Get browser history
• Get call history
• Get inbox SMS

155. Dendroid botnet -malware

156. Dendroid botnet - Manifest

157. Demo Time

158. DroidDream Malware
• Steal sensitive data
– IMEI –> block phone
– IMSI
– Device model
– SDK

159. DroidDream example #1 - Paint
• Access_coarse_location==GPS
• Read_phone_state

160. DroidDream example #1.1

161. DroidDream example #2 – Hotgirls

162. How to Protect Yourself
• Go to Settings → Security → Turn OFF "Allow
installation from unknown sources" .
• Always keep an up-to-date Anti-virus app
• Avoid unknown and unsecured Wi-Fi hotspots

163. Summary
• Obfuscate the code and mitigate the lack of
binary protection using anti-emulator,etc.
• Be aware of what permissions you’re giving to
the application.

164. • danielramirezmartin@gmail.com

166. References
• https://manifestsecurity.com/android-application-security/
• https://github.com/strazzere/anti-emulator
• Book:The mobile hackers handbook
• Book:Android Hackers Handbook
• http://darkmatters.norsecorp.com/2015/07/15/how-to-reverse-engineer-
android-applications/
• https://blog.netspi.com/attacking-android-applications-with-debuggers/
• http://briskinfosec.blogspot.co.uk/2014/07/apktool-for-android-security-
test-in.html
• https://decompileandsecureapk.wordpress.com/2014/05/10/decompile-
and-secure-android-apk/
• http://hackerz-inn.blogspot.co.uk/2014/12/android-botnet-dendroid-
step-by-step.html