4. Activity Life Cycle - onCreate
• Set the Activity's content View; Event Listeners
• Find references to any needed Views
• Passed-in Bundle allows a programmer to restore
the Activity to its previous status
5. Activity Life Cycle - onStart
• Called when the Activity becomes visible
• Initialize any properties requiring information
from the Window and contained Views
6. Activity Life Cycle - onResume
• Called when the Activity is visible and in the
foreground
• Initialize ability for user to interact with the
Activity
7. Activity Life Cycle - onPause
• Called when the Activity is no longer the
foreground
• Release system resources
8. Activity Life Cycle - onStop
• Called when Activity is no longer visible
• Perform larger operations like writing to a database
• Save Activity's state for onStart
9. Activity Life Cycle - onDestroy
• Called when the system is in need of
resources
• Last chance to free resources and avoid
memory leaks
11. Views
• A building block for
UI components
• Responsible for
drawing and event
handling
• Each View has an id
• findViewById(int)
Text box, check box,
radio button, time
picker, and image
view
12. XML
• Eclipse IDE
• Uses XML files to
set up the mobile
application
Android Layout File
13. XML - Android Manifest
• Contains properties
of the application
• Permissions, SDK,
Icon, Activities
Android Manifest File
14. XML - Layout
• Defines the layout
of the Activity
• Set View id values
• Could achieve the
same results
through java code
Android Layout File
15. XML – Other Files
• Menu – Defines the
Menu to bring up
• Dimens – Defines
dimensions with names
and values
• Strings – Defines
strings with names and
values
• Lint – Defines exclusion
or customization of lint
checks
• Styles – Defines the
style to use in the
Activity
• Attrs – Defines custom
attributes that may be
used in XML Layout
files
18. Intents
• Starts an activity or
service
• Service – operates in
the background without
a UI
• Intents can be sent to
other Apps
• sendBroadcast()
• sendOrderedBroadcast()
• sendStickyBroadcast()
19. Intents – Explicit vs. Implicit
• Explicit Intents
specify a
component to start.
• Implicit Intents give
a general action to
perform.
20. Intents - Intent-Filter
• Specified in the Manifest
file
• Contains the types of
Intents the app wants to
receive
• Allows one app to send
an Intent to another
• If no intent filters are
specified the activity
may only be started with
an explicit Intent
• To ensure security,
always use explicit
intents when starting a
Service
• Users can not see when
a Service starts
21. Permission
• Allows developers
to use security
features
• Provides additional
capabilities to
consumers that
otherwise would be
impossible
“A central design point of
the Android security
architecture is that no
application, by default,
has permission to
perform any operations
that would adversely
impact other
applications, the
operating system, or the
user”
22. Permission
• When an
Application is
installed the
consumer must
accept the
permissions
requested by an
application
• Permissions are
defined in the
Manifest file
24. Permission
• Camera/Microphone
• Allows consumers to use video chat
• Photos/Media/Files
• Allows consumers to send pictures they have
previously taken
• In order to give access, one must become
more vulnerable – like opening ports on your
router
28. Rooting/JailBreaking
• Rooting is the process of gaining root (a.k.a.
administrator or super user) to a smartphone.
• By default, all smartphones only give user’s
“guest” privileges.
• This is for both safety reasons and to prevent
users from doing things developers/carriers
don’t like (i.e. getting rid of their bloatware).
29. Pros and Cons to Root
Pros
• Download more apps and use
existing apps to fullest potential
• Flash custom ROMs
• Access locked
hardware/software features
• Tune performance
• No more bloatware
• Wi-Fi/Bluetooth Tethering
• Use apps designed for other
phones/carriers
• Install apps to an SD card
Cons
• If done incorrectly, can
possibly brick phone
• Voids any warranties you
have (even if you reverse
the root)
• Less stable/more bugs
30. General Security Vulnerabilities
• Flaws in Android OS itself
• Flaws in phone software/firmware
• Conventional browser based virus
• Vulnerabilities within downloaded apps
• Unconventional attacks (injecting code into
accelerometers i.e.)
31. Specific Vulnerabilities
• Backdoor.AndroidOS.Obad.a does not have an interface and works in
background mode, making it difficult to analyze, but that was only part of the
challenge, according to Unuchek. The application exploits an error in the
DEX2JAR software – generally used by researchers to convert APK files into
the Java Archive (JAR) format) – that disrupts the conversion of Dalvik
bytecode into Java bytecode and makes it difficult to run a statistical analysis
of the Trojan.
• Obad.a also targets an error in Android’s processing of the
AndroidManifest.xml file, which exists in every Android application to describe
the application’s structure, define its launch parameters and more. Although
Obad.a modifies AndroidManifest.xml so that it doesn’t comply with Google
standards, the vulnerability enables it to still be processed correctly,
complicating any attempt to run dynamic analysis on the application.
32. Next Time
• We will use a Metasploit (with a specific
module) to attack an android device.
• The “android device” will be a virtual android
machine running on an emulator
• We may also write a virus and Python and
deploy it to a device.
