Lecture Smartphone Security

Smartphone Security Overview
Jagdish Prasad Achara, Claude Castelluccia

INRIA Rhone-Alpes
5 decembre 2012
J. P. Achara, C. Castelluccia (INRIA Rhone-Alpes) Smartphone Security Overview 5 decembre 2012 1 / 49
Outline
1
Smartphones and Security
2
Security Mechanisms employed in iPhone and Android-powered Smartphones
3
Comparison between security mechanisms available in iPhone and
Android-powered smartphones
4
Security implications of modifying the default software stack of the devices
5
PRIVATICS and Smartphones
Outline
1
2
3
4
5
Smartphones and Security (1)
What is a Smartphone ?
Smartphone vs Feature phone ?

Above images from Google
Smartphone categorization :
1
Based on hardware present
However, well look hardware only from security point of view

2
Based on software running
Two dierent paradigms of OSes : Android and iOS

Smartphone security features
1
Security against physical hardware attack
2
Protection against malware
3
A mechanism to avoid illegal access to the smartphone and its data
Above image from Google
Smartphone vs other computing platforms
vs
Above images from Google
1
Smartphones provide mobile services, a computing platform, Internet access,
GPS navigation unit, Digital Camera etc. into a single device
2
Extreme mobile nature of smartphones
3
They are very personal to the users
Smartphone security importance
Above Images from Google
1
It stores a plethora of personal information !
2
Facebook, Twitter, Banking, Hotel Reservation Apps caches data
3
An illegitimate access to baseband hardware may result in big blunders
Outline
1
2
3
4
5
iPhone
iPhone Security Reference :
http://images.apple.com/ipad/business/docs/iOS_Security_May12.pdf
Software running on iPhone is :
Immutable code in Boot ROM
Firmware
Bootloaders (LLB, iBoot)
iOS (XNU kernel, system modules, services, apps)
Third-party Apps downloaded and installed from Apple AppStore

iOS :
a closed proprietary OS from Apple built on top of XNU kernel
The majority of iOS runs as non-privileged user mobile
The entire OS partition is mounted read-only
Remote login services arent included in the system software

iPhone Security features (1)
Secure Boot Chain
Immutable code is laid down during chip fabrication, and is implicitly trusted.
iOS security overview (1)
! a secure boot (chain of trust)
! at the very beginning: Apple root CA Public Key
trusted because stored in ROM
used to verify integrity and origin of code coming from Apple
! each step requires verifying the signature of the next
component before executing it
in case of failure, the boot process is stopped
12
immutable code +
Apple root CA PK
ROM
LLB
(low level bootloader)
iBoot iOS Kernel
verify signature,
then execute
verify signature,
then execute
verify signature,
then execute
Runtime process security by iOS kernel
Mandatory code signing extends the concept of chain of trust from the OS to
Apps
At runtime, code signature checks of all executable memory pages are made as
they are loaded
iOS security overview (2)
! third-party app verification
! all the official apps are signed by an Apple-issued certificate
possible since all app developers need to register to Apple
and get a valid certicate before any deposit on the AppStore
! this verification extends the chain of trust to apps
! signature verifications performed at runtime to make sure
the app has not been modified since it has been installed
13
iOS Kernel
verify signature,
then execute
app (1)
app (2)
app (3)

Data protection feature

!"#$%
'()*#+,
-#./
'0$(,1
-,1)*0
2*03() 4/+./,
564'789: ; '<67=>
633".?#@)/ A*)?,$$)*
5BCD EF*/( ./() (%, $.".?)/>
G,($ BCD
D-6 3#(% D-6 3#(%
D,3.?@)/ )H I#(# 3*)(,?@)/ H,#(F*, )/ .A%)/, '0$(,1 )/ 2%.3 5')2>
Four kinds of data protection :

1. Complete Protection
2. Protected Unless Open
3. Protected Unless First User Authentication
4. No Protection
Data protection feature (Contd...)
Class key protects le key.

Passcede censideratiens
lf a long password that contains only
numbers is entered, a numeric keypad
is displayed at the lock screen instead
of the full keyboard. A longer numeric
passcode may be easier to enter than a
shorter alphanumeric passcode, while
providing similar security.
Creating streng AppIe ID passwerds
Apple l0s are used to connect to a number
of services including iCloud, lacelime, and
iVessage. lo help users create strong
passwords, all new accounts must contain
the following password attributes.
At least eight characters
At least one letter
At least one uppercase letter
At least one number
lo more than three consecutive
identical characters
lot the same as the account name
9
File Contents
File Metadata
File Key
File System Key
Class Key
User Passcode
Device UID
lhe content of a 6le is encrypted with a per-6le key, which is wrapped with a class key
and stored in a 6le's metadata, which is in turn encrypted with the 6le system key. lhe
class key is protected with the hardware Ul0 and, for some classes, the user's passcode.
lhis hierarchy provides both exibility and performance. lor example, changing a 6le's
class only requires rewrapping its per-6le key, and a change of passcode |ust rewraps
the class key.
Passcodes
by setting up a device passcode, the user automatically enables 0ata Protection.
iOS supports four-digit and arbitrary-length alphanumeric passcodes. ln addition to
unlocking the device, a passcode provides the entropy for encryption keys, which are
not stored on the device. lhis means an attacker in possession of a device can't get
access to data in certain protection classes without the passcode.
lhe passcode is "tangled' with the device's Ul0, so brute-force attempts must be
performed on the device under attack. A large iteration count is used to make each
attempt slower. lhe iteration count is calibrated so that one attempt takes approximately
80 milliseconds. lhis means it would take more than 5 years to try all combinations
of a six-character alphanumeric passcode with lowercase letters and numbers, or
2 years for a nine-digit passcode with numbers only.
lo further discourage brute-force passcode attacks, the iOS interface enforces escalating
time delays after the entry of an invalid passcode at the lock screen. Users can choose
to have the device automatically wiped after 10 failed passcode attempts. lhis setting is
also available as an administrative policy through Vobile 0evice Vanagement (V0V)
and lxchange ActiveSync, and can also be set to a lower threshold.
Diagram from Apple iOS Security Document.
1
Complete Protection : Class key is protected with user passcode and UID.
2
Protected Unless Open : Using asymmetric elliptic curve cryptography to
generate back the per-le private key from per-le public key and private class
key.
3
Protected Untill First User Authentication : Protects data from attacks that
involve a reboot.
4
No Protection : Class key is protected only with UID. It is default class and
prevents reading the data directly from ash storage.
KeyChain for storing short but sensitive data and optionally, data can be
shared with other apps from the same developer
Keychain access APIs result in calls to the securityd framework.
securityd determines if a process can access a keychain item or not based on

that processs keychain-access-group and application-identier
entitlement
Keychain data protection class structure

Cempenents ef a keycbain item
Along with the access group, each keychain
item contains administrative metadata (such
as "created' and "last updated' time stamps).
lt also contains SlA-1 hashes of the attributes
used to query for the item (such as the
account and server name) to allow lookup
without decrypting each item. And 6nally, it
contains the encryption data, which includes
the following.
version number
value indicating which protection class
the item is in
Per-item key wrapped with the protection
class key
0ictionary of attributes describing the
item (as passed to SecltemAdd), encoded
as a binary plist and encrypted with the
per-item key
lhe encryption is AlS 128 in CCV (Calois/
Counter Vode), the access group is included
in the attributes and protected by the CVAC
tag calculated during encryption.
11
the secut|tyJ daemon determines which keychain items each process or app can
access. Keychain access APls result in calls to the securityd framework, which queries
the app's "keychain-access-groups' and the "application-identi6er' entitlement. Rather
than limiting access to a single process, access groups allow keychain items to be
shared between apps.
Keychain items can only be shared between apps from the same developer. lhis is
managed by requiring third-party apps to use access groups with a pre6x allocated to
them through the iOS 0eveloper Program. lhe pre6x requirement is enforced through
code signing and Provisioning Pro6les.
Keychain data is protected using a class structure similar to the one used in 6le 0ata
Protection. lhese classes have behaviors equivalent to 6le 0ata Protection classes, but
use distinct keys and are part of APls that are named di1erently.
Ava|ab|ty P|e Data Protecton Keychan Data Protecton
when unlocked lSlileProtectionComplete kSecAttrAccessiblewhenUnlocked
while locked lSlileProtectionCompleteUnlessOpen l/A
After 6rst unlock lSlileProtectionCompleteUntillirstUserAuthentication kSecAttrAccessibleAfterlirstUnlock
Always lSlileProtectionlone kSecAttrAccessibleAlways
lach keychain class has a "lhis device only' counterpart, which is always protected
with the Ul0 when being copied from the device during a backup, rendering it useless
if restored to a di1erent device.
Apple has carefully balanced security and usability by choosing keychain classes that
depend on the type of information being secured and when it's needed by the OS.
lor example, a vPl certi6cate must always be available so the device keeps a continuous
connection, but it's classi6ed as "non-migratory,' so it can't be moved to another device.
lor keychain items created by iOS, the following class protections are enforced.
|tem Accessb|e
wi-li passwords After 6rst unlock
Vail accounts After 6rst unlock
lxchange accounts After 6rst unlock
vPl certi6cates Always, non-migratory
vPl passwords After 6rst unlock
l0AP, Cal0Av, Card0Av After 6rst unlock
Social network account tokens After 6rst unlock
lome sharing password when unlocked
lind Vy iPhone token Always
ilunes backup when unlocked, non-migratory
voicemail Always
Safari passwords when unlocked
bluetooth keys Always, non-migratory
Apple Push loti6cation Service loken Always, non-migratory
iCloud certi6cates and private key Always, non-migratory
iCloud token After 6rst unlock
iVessage keys Always, non-migratory
Certi6cates and private keys installed by Con6guration Pro6le Always, non-migratory
SlV Pll Always, non-migratory
KeyChain for storing short but sensitive data and optionally, data can be
shared with other apps from the same developer (Contd...)
Encryption with device UID prevents restoring keychain items at another

device (even if its in No Protection class !)
Cempenents ef a keycbain item
Along with the access group, each keychain
item contains administrative metadata (such
as "created' and "last updated' time stamps).
lt also contains SlA-1 hashes of the attributes
used to query for the item (such as the
account and server name) to allow lookup
without decrypting each item. And 6nally, it
contains the encryption data, which includes
the following.
version number
value indicating which protection class
the item is in
Per-item key wrapped with the protection
class key
0ictionary of attributes describing the
item (as passed to SecltemAdd), encoded
as a binary plist and encrypted with the
per-item key
lhe encryption is AlS 128 in CCV (Calois/
Counter Vode), the access group is included
in the attributes and protected by the CVAC
tag calculated during encryption.
11
the secut|tyJ daemon determines which keychain items each process or app can
access. Keychain access APls result in calls to the securityd framework, which queries
the app's "keychain-access-groups' and the "application-identi6er' entitlement. Rather
than limiting access to a single process, access groups allow keychain items to be
shared between apps.
Keychain items can only be shared between apps from the same developer. lhis is
managed by requiring third-party apps to use access groups with a pre6x allocated to
them through the iOS 0eveloper Program. lhe pre6x requirement is enforced through
code signing and Provisioning Pro6les.
Keychain data is protected using a class structure similar to the one used in 6le 0ata
Protection. lhese classes have behaviors equivalent to 6le 0ata Protection classes, but
use distinct keys and are part of APls that are named di1erently.
Ava|ab|ty P|e Data Protecton Keychan Data Protecton
when unlocked lSlileProtectionComplete kSecAttrAccessiblewhenUnlocked
while locked lSlileProtectionCompleteUnlessOpen l/A
After 6rst unlock lSlileProtectionCompleteUntillirstUserAuthentication kSecAttrAccessibleAfterlirstUnlock
Always lSlileProtectionlone kSecAttrAccessibleAlways
lach keychain class has a "lhis device only' counterpart, which is always protected
with the Ul0 when being copied from the device during a backup, rendering it useless
if restored to a di1erent device.
Apple has carefully balanced security and usability by choosing keychain classes that
depend on the type of information being secured and when it's needed by the OS.
lor example, a vPl certi6cate must always be available so the device keeps a continuous
connection, but it's classi6ed as "non-migratory,' so it can't be moved to another device.
lor keychain items created by iOS, the following class protections are enforced.
|tem Accessb|e
wi-li passwords After 6rst unlock
Vail accounts After 6rst unlock
lxchange accounts After 6rst unlock
vPl certi6cates Always, non-migratory
vPl passwords After 6rst unlock
l0AP, Cal0Av, Card0Av After 6rst unlock
Social network account tokens After 6rst unlock
lome sharing password when unlocked
lind Vy iPhone token Always
ilunes backup when unlocked, non-migratory
voicemail Always
Safari passwords when unlocked
bluetooth keys Always, non-migratory
Apple Push loti6cation Service loken Always, non-migratory
iCloud certi6cates and private key Always, non-migratory
iCloud token After 6rst unlock
iVessage keys Always, non-migratory
Certi6cates and private keys installed by Con6guration Pro6le Always, non-migratory
SlV Pll Always, non-migratory
App Sandboxing
System installs each app in its own sandbox directory
Sandbox is a set of ne-grained controls that limit access by an app to other

apps and system resources.
To help apps organize their data, each sandbox directory contains several well-known subdirectories for placing
files. Figure A-1 shows the basic layout of a sandbox directory. For detailed information about the sandbox
directory and what belongs in each of its subdirectories, see File System Programming Guide .
Figure A-1 Sandbox directories in iOS
The iOS Environment
Security
2012-09-19 | 2012 Apple Inc. All Rights Reserved.
139
Above diagram from Apple
App Sandboxing Contd... (How it is implemented ?)
As a policy module for the TrustedBSD mandatory access control framework

Chaptor b
3andbox|ng
|O3 prov|dos mu|t|p|o |ayors ot oxp|o|tat|on m|t|gat|on. 0ata Exocut|on lrovont|on (0El) and Addross 3paco layout landom|zat|on (A3ll)
|ncroaso tho |nvostmont roqu|rod to ga|n codo oxocut|on, but othor m|t|gat|ons aro nocossary to ||m|t damago |n caso codo oxocut|on |s roa||zod.
App|o's |O3 sandbox, doscond|ng trom a s|m||ar systom tound |n O3 X, prov|dos ono mothod to ||m|t tho act|ons portormod by a procoss.
1ho goa| ot tho sandbox |s to ||m|t post-codo-oxocut|on act|ons by prov|d|ng an |ntortaco tor bound|ng tho bohav|or ot a procoss. lmag|no a l0|
rondor|ng app||cat|on: Ono subsystom ot tho app||cat|on parsos tho oponod t||o to produco an |ntorna| roprosontat|on. Anothor subsystom, |n
chargo ot rondor|ng th|s documont to tho scroon, consumos th|s |ntorna| roprosontat|on. 3ocauso tho pars|ng subsystom |s most vu|norab|o to
attack whon |t procossos usor-supp||od |nput, |t noods accoss to tho |nput t||o and ||tt|o o|so. 3y provont|ng th|s subsystom trom opon|ng othor t||os,
oxocut|ng othor programs, or us|ng tho notwork, an attackor's act|ons post-codo-oxocut|on aro ||m|tod. ln thoory, th|s |s stra|ghttorward and oasy to
|mp|omont, |n pract|co, bound|ng tho oxpoctod bohav|or ot a procoss |s d|tt|cu|t and prono to orror.
1h|s chaptor d|scussos tho dos|gn and |mp|omontat|on ot tho |O3 sandbox. 3y stopp|ng through tho codo usod to cont|guro and ontorco tho
prot||o tor a g|von procoss, you ga|n tho know|odgo noodod to portorm moro advancod aud|ts ot tho |O3 sandbox ontorcomont systom. Vost ot tho
chaptor |s spont d|scuss|ng tho undocumontod parts ot tho systom.
undoratanding tho 5andbox
Or|g|na||y codonamod 3oatbo|t,' tho App|o sandbox t|rst ox|stod on O3 X. 1ust ||ko AV|l, d|scussod |n Chaptor 4, |t |s |mp|omontod as a po||cy
modu|o tor tho 1rustod330 mandatory accoss contro| (VAC) tramowork. 1rustod330 was portod trom |roo330 to tho XlU korno|. 1ho sandbox
tramowork adds s|gn|t|cant va|uo by prov|d|ng a usor spaco cont|gurab|o, por-procoss prot||o on top ot tho 1rustod330 systom ca|| hook|ng and
po||cy managomont ong|no. ln othor words, 1rustod330 prov|dos tho hook|ng, but tho sandbox prov|dos tho bra|ns to ontorco a cont|gurod prot||o.
1ho sandbox |s mado up ot tho to||ow|ng compononts:
A sot ot usor spaco ||brary tunct|ons tor |n|t|a||z|ng and cont|gur|ng tho sandbox
A Vach sorvor tor hand||ng |ogg|ng trom tho korno| and ho|d|ng probu||t cont|gurat|ons
A korno| oxtons|on us|ng tho 1rustod330 All tor ontorc|ng |nd|v|dua| po||c|os
A korno| support oxtons|on prov|d|ng a rogu|ar oxpross|on ong|no tor ova|uat|ng somo po||cy rostr|ct|ons dur|ng ontorcomont
||guro b.1 shows how thoso compononts aro ro|atod.
Figuro 5.1 Compononts ot tho |O3 sandbox
3andbox|ng an app||cat|on bog|ns w|th a ca|| to tho 11r.,:~- tunct|on :~nJr1n1. 1h|s tunct|on usos tho 11r:~nJr.J,11r ||brary to turn a
human-roadab|o po||cy dot|n|t|on (doscr|b|ng ru|os s|m||ar to don't a||ow accoss to t||os undor :~i.~') |nto a b|nary tormat that tho korno|
oxpocts. 1h|s b|nary tormat |s passod to tho -~:,:~11 systom ca|| hand|od by tho 1rustod330 subsystom. 1rustod330 passos tho sandbox
|n|t|a||zat|on roquost to tho .~nJr.i~ korno| oxtons|on tor procoss|ng. 1ho korno| oxtons|on |nsta||s tho sandbox prot||o ru|os tor tho curront
procoss. Upon comp|ot|on, a succosstu| roturn va|uo |s passod back out ot tho korno|.
Onco tho sandbox |s |n|t|a||zod, many ot tho tunct|on ca||s hookod by tho 1rustod330 |ayor pass through .~nJr.i~ tor po||cy ontorcomont.
Above diagram from iOS Hackers Handbook
sandboxd begins with calling sandbox init in libSystem > Uses

libsandbox.dylib to turn human-readable policy Only allow access to
/priavte/var/mobile/Apps/AppHome in binary format > Passes to
mac syscall system call handled by TrustedBSD and eventually to
Sandbox.kext for processing > kext installs sandbox prole for that process
Use of entitlements for access control
Key-value pairs allowing authentication beyond runtime factors like unix user
id.
Entitlements are digitally signed.
Extensively used by System Apps and daemons to perform specic privileged

tasks that would otherwise require the process to be run as root.
Greatly reduces the potential for privilege escalation by a compromised system

app or daemon.
1h|s codo rovoa|s that tho app||cat|on |s s|gnod by an |nd|v|dua| dovo|opor, |n th|s caso Char|os V|||or. 1h|s app w||| bo rojoctod on phonos
w|thout tho corroct prov|s|on|ng prot||o. lt th|s app |s subm|ttod to tho App|o App 3toro, and |t |s approvod, App|o wou|d s|gn |t and mako |t ava||ab|o
tor down|oad. ln th|s caso, |t cou|d bo run on any dov|co, wh|ch you can soo:
J~:1n -J ~n.,.1.J:.~
.~u~r1~-J:~.:-111~.ri1nn~-
ri.~n.,.1.J:.~~n.,.1.J:
1J~n11~.--.11i~-~..~n.,.1.J:
..-~-runJ1~ .1n n~n-o n1n +~.-)
cJ~u1.~., -.1 :1.~-1. 1~:-+nn~) n~:n~:-+.
1~1n-~-r~JJ~J
n~:n ,~-:n~1 :1.~-.
cun~:n--J11J..1~J.Jr.~~-r~.-.1J11.~
.1n~u.~ :1.~-..-.
nunory=nppio nono os nppicaon sqnnq
nunory=nppio nono corrcaon nunory
nunory=nppio noo cn
.1n~J 11-~-u1 .., .11 ..... ~n
1n.11: ~n.1~:-.
.~~1~J .~:u.~: .u1~:-. 11~:-
1n~.n~1 .~u1.~-~n: un-. :1.~-..
low, tho app |s s|gnod by tho App|o |lhono O3 App||cat|on 3|gn|ng author|ty, wh|ch |s accoptod by dotau|t on a|| dov|cos.
1ho oxocutab|os that sh|p on an |lhono may bo s|gnod ||ko tho App 3toro apps, but typ|ca||y, thoy aro s|gnod w|th an ad hoc mothod as shown
horo:
J~:1n -J c--c~n~.
.~u~r1~-J:~.:-111~.ri1nn~-ri.c--c~n~.
1J~n11~.--.~1~.c--c~n~.
..-~-n~n-o n1n +~.-)
cJ~u1.~., -.1 :1.~-. 1~:-.+~Jn) n~:n~:-.1.+.
1~1n-~-r~JJ~J
n~:n ,~-:n~1 :1.~-.
cun~:n-.~.rJJ~..~JJ.r-.JJ.1~.r~
sqnauro=adnoc
1n.11:-n runJ
.~~1~J .~:u.~:-nn~
1n~.n~1 .~u1.~-~n: un-1 :1.~-...
A|ono, th|s |mportant oxocutab|o wou|d not oxocuto, bocauso |t |s not s|gnod. |owovor, as you soo short|y, thoro aro othor ways bos|dos hav|ng a
part|cu|ar s|gnaturo, that codo |s st||| trustod. ln th|s caso, tho b|nary's hash |s bakod r|ght |nto tho korno| |n tho stat|c trust cacho. Exocutab|os whoso
hashos aro conta|nod |n tho stat|c trust cacho aro automat|ca||y a||owod to oxocuto as |t thoy had a va||d and accoptod s|gnaturo.
|naido EntitIomonta
3|gnod app||cat|ons may a|so conta|n a p||st t||o spoc|ty|ng a sot ot ont|t|omonts to grant tho app||cat|on. Us|ng tho 1J1J too|, producod by 3aur|k,
you can ||st tho sot ot ont|t|omonts tor a g|von app||cat|on:
+ 1J1J -~ ~n.,.1.J:
-1 ~.:1n-1. ~nJ1n-J1.--
uoc1... 11: .J..1c -~1~u1u ..1.1 1..|
n.....~1~.-u1u:..~.,.1:-1..JJ
11: ~.:1n-1.
J1
i~,~11~1n-1J~n11~.i~,
:.1nc-.\\...-.11i~-~..~n.,.1.J::.1n
i~,~:-~n1.n-~ni~,
:.1n.Ju1n:.1n
i~,i~,n~1n-~~::-.u:i~,
~..~,
:.1nc-.\\...-.11i~-~..~n.,.1.J::.1n
~..~,
J1
11:
1ho app||cat|on |dont|t|or prov|dos a un|quo prot|x tor oach app||cat|on. 1ho koycha|n-accoss group prov|dos a way tor apps to socuro tho|r data.
Ent|t|omonts prov|do a mochan|sm tor somo apps to havo moro or towor pr|v||ogos than othor apps, ovon |t thoy aro runn|ng as tho samo usor and
havo tho samo sandbox ru|os. A|so, as d|scussod oar||or, tho ont|t|omonts that can bo g|von out aro a tunct|on ot tho prov|s|on|ng prot||o, and so
App|o can not on|y ||m|t tho tunct|ona||ty ot corta|n apps, but can a|so ||m|t tho tunct|ona||ty ot a|| apps wr|tton by a part|cu|ar dovo|opor.
|or anothor oxamp|o, cons|dor gdb, tho GlU dobuggor, wh|ch you can got trom tho |O3 30K:
+ 1J1J -~ u:.r1nJr
uoc1... 11: .J..1c -~1~u1u ..1.1 1..|
n.....~1~.-u1u:..~.,.1:-1..JJ
11: ~.:1n-1.
J1
i~,-.~1~.:.1nr~.J.J~ru~11~1n:i~,
.u~
i~,~-~:i-~11.i~,
.u~
i~,~:i.1J-~11.i~,
.u~
J1
11:
You'|| not|co that gdb has a tow add|t|ona| ont|t|omonts that aro nocossary to a||ow |t to dobug othor app||cat|ons. You |oarn about anothor
Protection of memory from the exploitation of memory corruption bugs
Use of ASLR (Address Space Layout Randomization)
Memory pages marked as both writable and executable can be used by

Apps having Apple-only dynamic-codesigning entitlements. Safari uses this
entitlements for its JavaScript JIT compiler.
Diacovoring Dynamic Codo 5igning
|rom tho t|mo codo s|gn|ng was |ntroducod |n |O3 2.0 unt|| |O3 4.8, tho prov|ous|y d|scussod doscr|pt|on ot codo s|gn|ng was a|| that ox|stod. A||
codo noodod to bo s|gnod, and no uns|gnod momory cou|d bo oxocutod. |owovor, th|s str|ct codo s|gn|ng po||cy ru|od out tochno|og|os ||ko 1ust-ln-
1|mo comp|||ng (1l1), wh|ch |s a toaturo that a||ows bytocodo |ntorprotors to run s|gn|t|cant|y tastor. 3ocauso many 1ava3cr|pt |ntorprotors ut|||zo 1l1,
App|o's dos|ro to havo Vob||o3atar| run tastor t|na||y outwo|ghod |ts dos|ro tor tota| contro| ovor a|| oxocut|ng codo. ln |O3 4.8, App|o |ntroducod tho
|doa ot dynam|c codo s|gn|ng to a||ow 1l1.
1o run tastor, bytocodo |ntorprotors us|ng 1l1 dotorm|no what mach|no codo tho bytocodo |s try|ng to run, wr|to tho mach|no codo to a buttor,
mark |t oxocutab|o, and thon oxocuto |t w|th tho actua| procossor. W|th typ|ca| |O3 codo s|gn|ng, th|s |s |mposs|b|o. 1o a||ow 1l1, but st||| koop much
ot tho socur|ty ot tho or|g|na| codo s|gn|ng schomo, App|o choso a comprom|so. lt wou|d a||ow on|y corta|n procossos (tor oxamp|o, Vob||o3atar|)
to mako a momory rog|on that was wr|tab|o and oxocutab|o to portorm tho|r 1l1 work. |urthormoro, tho procoss cou|d mako oxact|y ono such
rog|on. Any attompts to mako add|t|ona| wr|tab|o and oxocutab|o rog|ons wou|d ta||.
Why NobiIo5atari |a 5o 5ociaI
Us|ng 1J1J, as shown oar||or, you can soo tho spoc|a| ont|t|omont g|von to Vob||o3atar| - dynam|c codo s|gn|ng:
+ 1J1J -~ ~11~1n:nr11~.~~.1.~nr11~.~~.1
-1 ~.:1n-1. ~nJ1n-J1.--
uoc1... 11: .J..1c -~1~u1u ..1.1 1..|
n.....~1~.-u1u:..~.,.1:-1..JJ
11: ~.:1n-1.
J1
i~,-.~1~..~~uJ1.~11.-~-.-J~J~i~,
.u~
i~,-.~1~..~-~J1~.~11.-.~~J-n~n-
1~,r~ii~,
.u~
i~,-.~1~.-~n~~Jn1u.~1n..11~J-~~::i~,
.u~
i~,-.~1~.:.1nr~.J.~n:~n:11~u.1i~,
.u~
i~,dynac-codozqnnqi~,
ruo
i~,i~,n~1n-~~::-.u:i~,
~..~,
:.1n-.~1~.n~..i:.1n
:.1n-.~1~.1J~n11~::.1n
:.1n-.~1~.-r11~:~~.1:.1n
~..~,
i~,1~.--~11~1ni~,
.u~
i~,:~~r~1-.11~:i~,
~..~,
:.1nnr11~.~~.1:.1n
~..~,
J1
11:
On|y oxocutab|os w|th th|s ont|t|omont aro a||owod to croato thoso spoc|a| rog|ons, and Vob||o3atar| has th|s ont|t|omont.
lt you |ook |ns|do tho WobK|t sourco codo, |t |s poss|b|o to soo tho 1l1 spaco got a||ocatod. lamo|y, w|th|n 1ava3cr|ptCoro, |n tho t||o
.~u~r1~~11~..1~J\n.1., you soo tho a||ocat|on tako p|aco:
+J~1n~ nn~...~c. +n~...1\~1. ) n~.~|o| ) n~.11)
ci u ~n ~JJ.~:: ~11~~ ~, u:1n n~ 11.1n .~1~.
1 r1: .~., :~, 1n u:~.:~~ i1J:.
. r1: .~nJ-n~:: . ~....
.1 r1: .~., ~ 1~~: :~, ~11n~J .1n1n n~ 1~~1
n~ ~~~r1~:.
.u - ~: ~ ~-.~., ..i~.unJ . :-~ 1u1n .r1~-:

+.J~...r1~--1.-.),
. n. 1n:~~J .. r1: ~... 1~: :1i .1n .. r1:
.~nJ-1.~1n 1u: .., .n1n :nu1J u u :-~.n~.~ 1n n~
-1JJ1~ u:~:~~ +1n n~ ~JJ.~:: .~n~
. .. .).
1n. .~nJ-.~1n - ;
+1 \n.oo.~...
.~nJ-.~1n - ~..~nJ-+) . ++1 ..) - 1);
.~nJ-.~1n +- +1 .);
.~nJ-.~1n - .1;
+~nJ1
-r~:~ - --~+.~1n~..~~:1J+.~nJ-.~1n),
-~1n~~.1.~, 1|111~...o1.c11o|..~c., nn~...~c.,
\n1~c.o..x.cJ1~...~..oc~1o.n.no.., );
1o soo tho ca|| |n act|on, sot a broakpo|nt at --~ w|th a cond|t|on tor tho protoct|on t|ags to bo roadab|o, wr|tab|o, and oxocutab|o (lWX), tor
oxamp|o, tor tho protoct|on t|ags (kopt |n ..) to bo .
+Jr) ~~n nr11~.~~.1
~~n1n .~:: 1-.
...
+Jr) r.~~i --~
..~~i1n 1 ~ .1..~
System Software Personalization
To prevent devices from being downgraded to older versions that lack the
latest security features
iOS Software Updates can be installed using iTunes or OTA on the device.
!"#$%& () *%+!,%
-../% 0$&12//23($ 4%)+%)
56&72../%7,(89
!"#$ &: ;<%,=& !> #.6)2?% !& 2+2!/2@/%
!"#$ '7 ;)A.1(6)2.<!, 8%2&#)%8%$1& >()
%2,< @#$?/% 1( @% !$&12//%?B $($,%B C;0*
!"#$ (7 &!6$%? 5;)A.1(6)2.<!,
8%2&#)%8%$1 D $($,% DC;0*9
Application Access to standard iOS APIs
Apple claims to verify all submitted Apps for legitimate API access. But with
each iOS revision, control is being transferred to the user.
Mere access to private data access using APIs prompts a warning to the user
and user has the option to allow/deny it.
However, there is no mechanism to control the way accesssed information is

being used ! RESEARCH TOPIC!
iPhone Security Architecture
Does it make any sense now?
Apple designed the iOS platform with security at its core. Keeping information secure
on mobile devices is critical for any user, whether they're accessing corporate and customer
information or storing personal photos, banking information, and addresses. because
every user's information is important, iOS devices are built to maintain a high level of
security without compromising the user experience.
iOS devices provide stringent security technology and features, and yet also are easy to
use. lhe devices are designed to make security as transparent as possible. Vany security
features are enabled by default, so ll departments don't need to perform extensive
con6gurations. And some key features, like device encryption, are not con6gurable, so
users cannot disable them by mistake.
lor organizations considering the security of iOS devices, it is helpful to understand
how the built-in security features work together to provide a secure mobile computing
platform.
iPhone, iPad, and iPod touch are designed with layers of security. low-level hardware
and 6rmware features protect against malware and viruses, while high-level OS features
allow secure access to personal information and corporate data, prevent unauthorized
use, and help thwart attacks.
lhe iOS security model protects information while still enabling mobile use, third-party
apps, and syncing. Vuch of the system is based on industry-standard secure design
principlesand in many cases, Apple has done additional design work to enhance
security without compromising usability.
lhis document provides details about how security technology and features are
implemented within the iOS platform. lt also outlines key elements that organizations
should understand when evaluating or deploying iOS devices on their networks.
System arcbitecture: lhe secure platform and hardware foundations of iPhone, iPad,
and iPod touch.
ncryptien and Data Pretectien: lhe architecture and design that protects the user's
data when the device is lost or stolen, or when an unauthorized person attempts to
use or modify it.
Netwerk security: lndustry-standard networking protocols that provide secure
authentication and encryption of data in transmission.
Device access: Vethods that prevent unauthorized use of the device and enable it
to be remotely wiped if lost or stolen.
iOS is based on the same core technologies as OS \, and bene6ts from years of
hardening and security development. lhe continued enhancements and additional
security features with each ma|or release of iOS have allowed ll departments in
businesses worldwide to rapidly adopt and support iOS devices on their networks.
Device Key
Croup Key
Apple Poot Certi6cate
Crypto Lngine
Kernel
OS Partition
User Partition
Data Protection Class
App Sandbox
Lncrypted Pile System
Software
Hardware and
Pirmware
|ntroducton
3
Security architecture diagram of iOS provides
a visual overview of the di1erent technologies
discussed in this document.
Software running on Android-powered smartphones is :
Immutable code in Boot ROM
Firmware
Bootloader
Android (Linux kernel, system modules, services, apps)
Third-party Apps (No restriction for the source !)

Android :
Linux based OS developed by Google in conjuction with Open Handset

Alliance
A small amount of Android OS code runs as root.
System partition is mounted as read-only and contains Kernel, OS libraries,

Application Runtime (DVM), Application framework and System Apps.
Android apps are most often written in Java and run in the DVM.
Android Software Stack
All software above the kernel (operating system libraries, application
framework, application runtime, system and third party apps) run within
the Application Sandbox.
Taken from Android Open Source website.
Android Security features (1)
Secure Boot Chain
Depends on manufacturer and also, on cellular service provider if its in

contract.
Sometimes it exists and other times it doesnt.
But unlike iPhones, it doesnt extend till Apps in any case.
FileSystem Encryption
is performed in the kernel using dm-crypt after Android v 3.0.
Not on by default.
Some custom ROM builders had even removed this feature

completely...strange enough !
Protection of memory from exploitation of memory corruption bugs
A memory corruption error will only allow execution of arbitary code in the
context of that process.
Latest versions use ASLR.

Application Sandbox
Android System assigns a unique user id to each Android App and runs it as
that user in a separate process.
Kernel enforces security at the process level through standard Linux facilities.
Apps get a dedicated part of the le system which acts as home for that App.
Application Signing
All installed apps must be signed
Helps in application updates
Apps coming from same developer can share the same user id (App developer
can specify that in the manifest !)
System Partition and Safe Mode
System partition contains Androids kernel, OS libraries, application runtime,

application framework and system apps. It is set to read-only.
In Safe mode, only System Apps are loaded i.e. user can boot the phone in an
environment free of third-party software.
Android Updates
OTA or side-loaded updates.
OTA mechanism isnt described ; but with side-loaded updates downgrade is

possible
Flashing a new system image always leads to erasing all the data on the device.
Application Access to standard Android APIs
Makes use of Manifest le. All needed-permissions need to be stored in this le.
User has to either allow/deny all needed permission for the app at install time.
Application Access to standard Android APIs (Contd...)
User permission is asked for accesssing user private info, internet access, SIM
card access and cost-sensitive activities (telephony, SMS, network/data,
In-App billing, NFC Access etc.)
Taken from Android Open Source website.
Interprocess communication
Processes can communicate using any of the traditional UNIX methods e.g.
le system, local sockets. Linux permissions still apply !
Androids new IPC mechanisms :
Binder, Services, Intents and ContentProviders
Digital Rights Management
Provides a DRM framework that lets applications manage rights-protected

content according to the license constraints
Outline
1
2
3
4
5
Comparision between security measures employed in
iPhone and Android-powered Smartphones (1)
Secure Boot Chain
iPhone secure boot chain extends to apps whereas in case of Android-powered

smarthpones, at max, it extends to kernel and system apps.
Moreover, in Android-powered smartphones, it depends on device

manufacturer. For example, Googles nexus series smartphones have unlocked
bootloader and any custom-prepared system image can be ashed whereas
other manufacturers (Samsung, HTC etc.) sell their devices in conjuction with
cellular service providers and bootloader is generally locked to prevent user to
bypass the restrictions put by them.
Data protection features
In iPhone ash storage, all user data always (by default) remains encrypted
and is, at least, protected by UID whereas encryption is not on by default in
Android.
iPhone prevents user data in dierent protection classes to balance security

and availabilty. Data in certain protection classes isnt accessible when the
screen is passcode locked whereas Android decrypts whole user partition rst
time it boots up by the passcode provided by the user.
In Android, all or part of the user data can be accessed by adb depending on
the fact that it is Rooted or not even when the device is lost with screen
lock. Its not the case with iPhone.
Its more complex to hack/bypass the data protection feature in iPhone by

apps running as privileged user as it makes use of both hardware and software
stack of the device.
App Sandboxing
In Android, each app runs in a separate process with dierent user id (except
the apps from the same developer if the developer wants to and species it in
the apps manifest le) whereas all iPhone apps runs in dierent process with
same unprivileged user id (user called mobile).
In iPhone, sandboxd daemon installs a dierent sandbox prole at the start of

each process by implementing a policy module for TrustedBSD mandatory
access control (MAC) framework.
App access to standard APIs
In Android, app requested permissions are allowed/denied at install time

whereas iPhone prompts the user to allow/deny access to private data at
runtime. Additionally, in case of iPhone, application verication is done by
Apple after developers request their apps to be put on Apple App store.
However, its not public how the verication is done.
System upgrades
iPhone system software upgrades prevents use to downgrade by making use of

device-specic upgrade. Its possible to downgrade Android in case of
side-loaded upgrade if one is available.
OTA upgrades must be secured in both systems ; however, Android OTA

upgarde is not documented.
What if you lose Android-powered smartphone or iPhone ?
If device is passcode locked : Android keeps the decryption key used to encrypt
the user data in the memory till the device is not powered o whereas iPhone
wipes it out from the memory 10 seconds after user locks the phone rendering
the data inaccessible in certain protection classes (classes which are protected
by user passcode !)
If ash memory is taken out of the device to read the data : iPhone
non-volative ash memory data wont be accessible in any case if someone
takes it out and tries to read the data whereas on Android, it wont be
accessible only if the user has explicitely switched on the encryption feature.
Outline
1
2
3
4
5
Modifying the default software stack of iPhone (1)
A very popular term Jailbreaking is coined for removing the restrictions
put by Apple on its amazing device by modifying the software stack of the
device !
The question is : Why one would like to change the software stack ?
An open platform for which developers can write software
If one would like to have total control over the device
To bypass cellular locks and other restrictions put by carrier e.g. WiFi tethering
To pirate iPhone Apps
To evaluate the security of the device
To do some frauds e.g. by changing baseband code or to fake things e.g. by

changing network data.
Jailbreaking (Behind the scene) Reference : iOS Hackers Handbook
Case of A4 Soc devices (iPhone 4, 3GS, iPad 1) having Bootrom exploit !
Step 1. Exploiting the BootROM :
The vulnerability exploited is a heap-based buer overow in the USB DFU

stack of the bootrom.
Step 2. Booting the custom ramdisk :
When the ramdisk is booted, the kernel executes modied /sbin/launchd.
It mounts both partitions as readable and writable.
Eventually, an executable called jailbreak takes over and perfoms all of the
following steps.
Step 3. Jailbreaking the FileSystem :
To survive reboot and add additional services, one requires to modify the root
lesystem.
(Re)mounting the root lesystem with read and write permission is usually the
rst step after acquiring root permissions.
To persist these changes across reboots, /etc/fstab is changed to mount

system partition as readable and writable
Jailbreaking (Behind the scene) Contd...
Step 4. Installing the AFC2 service :
The Apple File Connection (AFC) is a le transfer service.
lockdownd daemon (A daemon is a program which keeps running in the

background !) provides two services named com.apple.afc and
com.apple.crashreportcopymobile to access /var/mobile/Media and
/var/mobile/Library/Logs/CrashReporter via USB.
com.apple.afc2 service is installed by adding the below lines in the lockdownd

conguration le (/System/Library/Lockdown/Services.plist).
~:~r t||o on tho root t||osystom:
J~J1:i:1 n: . 1
J~J1:i:. .1~~~. n: ..,n:u1J,nJ~ .
As you can soo, tho mount cont|gurat|on tor tho data part|t|on conta|ns tho t|ags nJ~ and n:u1J. 1ho nJ~ t|ag onsuros that dov|co nodos that
m|ght ox|st on tho wr|tab|o data part|t|on, duo to a t||osystom-|ovo| attack, w||| bo |gnorod. 1ho n:u1J t|ag to||s tho korno| to |gnoro tho :u1J b|t on
oxocutab|os w|th|n tho data part|t|on. 1ho :u1J b|t |s usod to mark oxocutab|os that nood to run as root, or gonora||y as a d|ttoront usor than tho ono
oxocut|ng |t. 3oth thoso t|ags aro, thorotoro, an add|t|ona| sma|| ||no ot dotonso |ns|do |O3 aga|nst pr|v||ogo osca|at|on oxp|o|ts.
1h|s dotau|t cont|gurat|on |s a prob|om tor a|| ja||broaks, no mattor whothor bootrom-|ovo| or usor|and, bocauso thoy usua||y roqu|ro mak|ng
mod|t|cat|ons to tho root t||osystom, tor oxamp|o to surv|vo roboots or add add|t|ona| daomons and sorv|cos. 1ho t|rst act|on ot oach ja||broak attor
acqu|r|ng root porm|ss|ons |s, thorotoro, to (ro-)mount tho root t||osystom as roadab|o and wr|tab|o. 1o pors|st th|s chango across roboots, tho noxt
stop |s to rop|aco tho systom's ~:~r t||o w|th somoth|ng ||ko th|s:
J~J1:i:1 n: .. 1
J~J1:i:. .1~~~. n: .. .
1h|s now t||osystom cont|gurat|on |oads tho root t||osystom as roadab|o and wr|tab|o and romovos tho n:u1J and nJ~ t|ags trom tho mount
cont|gurat|on ot tho socond part|t|on.
|nataIIing tho untothoring ExIoit
Evory t|mo a now vors|on ot |O3 comos out, prov|ous|y known vu|norab|||t|os aro c|osod. 1horotoro, thoro |s a ||m|tod t|mo w|ndow dur|ng wh|ch
.~J:n. can ja||broak now t|rmwaro on o|d dov|cos, but cannot |nsta|| an untothor|ng oxp|o|t.
Onco a now untothor|ng oxp|o|t |s ava||ab|o, .~J:n. gots mod|t|od by |ts author to |nsta|| |t. And bocauso ovory now sot ot oxp|o|ts |s d|ttoront,
thoy a|ways roqu|ro d|ttoront |nsta||at|on stops.
3ut, a|though tho actua| untothor |nsta||at|on |s d|ttoront, |t usua||y comos down to just ronam|ng or mov|ng somo t||os on tho root t||osystom and
thon copy|ng somo add|t|ona| t||os onto |t. Whon you docomp||o tho curront vors|on ot .~J:n., you can soo that |t supports |nsta|||ng untothors tor
most ot tho |O3 vors|ons botwoon 4.2.1 and b.0.1, and soo oxact|y what t||os aro roqu|rod tor oach untothor.
|nataIIing tho AFC2 5orvico
1ho App|o |||o Connoct|on (A|C) |s a t||o transtor sorv|co that runs on ovory |lhono and a||ows you to accoss t||os w|th|n tho mod|a d|roctory
~.-r11~n~J1~ ot tho |lhono v|a U33. 1h|s sorv|co |s prov|dod by tho 1iJ.nJ daomon and |s namod -.~1~.~. |owovor, 1iJ.nJ
on|y prov|dos accoss to tho sorv|co, |ts actua| |mp|omontat|on |s w|th|n tho ~J daomon. lt can bo accossod trom a Vac through tho
nr11~u~1~..~-~..i or through tho 11un~:nr11~u~1~.J11 on a W|ndows lC.
A socond 1iJ.nJ sorv|co |s poworod by ~J. lt |s rog|storod w|th tho namo -.~1~..~:n.~.,-r11~. lt |s usod to copy tho
Crashloportor roports trom tho dov|co to tho computor, and |t |s ||m|tod to prov|d|ng road and wr|to accoss to tho
~.-r11~.1r.~.,.:c.~:n.~.~. d|roctory and |ts subd|roctor|os on|y.
3ocauso both thoso sorv|cos run w|th tho porm|ss|ons ot tho -r11~ usor on|y and aro |ockod |nto spoc|t|c d|roctor|os, thoy aro too ||m|tod to bo
usotu| to ja||broakors. 1horotoro, .~J:n. and sovora| othor oar||or ja||broak|ng too|s rog|stor an add|t|ona| sorv|co w|th 1iJ.nJ ca||od
-.~1~.~.. 1h|s sorv|co usos tho ~J daomon to prov|do road and wr|to accoss to tho who|o t||osystom w|th root porm|ss|ons, wh|ch |s a
qu|to dangorous toaturo ot ja||broaks that tho major|ty ot usors do not know about. lt bas|ca||y moans that attach|ng a ja||brokon |lhono w|thout a
passcodo, or |n an un|ockod stato, to a U33 powor stat|on or anothor porson's computor g|vos tho othor s|do road and wr|to accoss to tho who|o
t||osystom w|thout usor |ntoract|on. 1hoy can stoa| a|| your data or add rootk|ts.
1ho -.~1~.~. sorv|co |s |nsta||od by chang|ng tho 1iJ.nJ cont|gurat|on w|th|n tho .,:~-.1r.~.,.iJ.n.~.1~:.11: t||o. lt
|s a norma| .11: t||o and thorotoro can bo mod|t|od w|th tho standard too|s or All tor .11: t||os. ln caso ot .~J:n. tho now sorv|co |s |nsta||od
by add|ng tho to||ow|ng ||nos to tho t||o:
i~,-.~1~.~.i~,
J1
i~,~11.Jn~1~~J.~.1~i~,
.u~
i~,.~r~1i~,
:.1n-.~1~.~.:.1n
i~,...~-~.u-~n:i~,
~..~,
:.1nu:.11r~~~J:.1n
:.1n--1iJ.n:.1n
:.1n-J:.1n
:.1n:.1n
~..~,
J1
3ocauso tho t||osystom ja||broak and tho now A|C2 sorv|co aro prov|dod by s|mp|o cont|gurat|on changos and do not roqu|ro uns|gnod b|nar|os
to bo oxocutod, thoy both work attor roboot, ovon |t a dov|co has no untothorod ja||broak ava||ab|o.
|nataIIing Baao utiIitioa
App|o doos not sh|p tho |lhono w|th a UllX sho||, so |t |s no surpr|so that tho r1n and u:.r1n d|roctor|os on tho root t||osystom aro noar|y ompty
and not t|||od w|th a|| tho oxocutab|o b|nar|os you oxpoct to t|nd |n thoso d|roctor|os. ln tact, tho |atost vors|on ot |O3 b.0.1 sh|ps w|th on|y t|vo
pro|nsta||od oxocutab|os |n thoso d|roctor|os:
r1n1~unn1
u:.r1n~.J1~.
u:.r1nuu-.~:~r~nJc.~:n
u:.r1n.~.1
Jailbreaking (Behind the scene) Contd...
Step 5. Installing base utilities :
Apple doesnt ship the iPhone with a UNIX shell.
It comes with launchctl executable in /bin/ directory and awd ice3,

DumpBasebandCrash, powerlog and simulatecrash executables in /usr/bin/
directory.
So, all these basic utility tools like mv, cp, tar, gzip, gunzip, ldid etc. are
installed.
Step 6. Application Stashing and Bundle Installation :
A new directory /var/stash is created on the data partition and some

directories like /Applications, /Library/Ringtones, /Library/Wallpaper are
moved to /var/stash directory from root lesystem.
The moved directories from root lesystsem are then repalced by symbolic
links to the new location in /var/stash.
In the end, bundles (tar archives) like Cydia are unpacked into the
/Applications directory and registered in a systemwide installation cache
stored in /var/mobile/Library/Caches/com.apple.mobile.installation.plist.
Security implications of Jailbreaking (1)
If your phone is lost/stolen, think of AFC2 service installed during

Jailbreaking !
Someone can just copy all your data !
and additionally, install some remote-login tools, spyware and rootkit and give
you back the phone !
Apps installed on a Jailbroken phone can get root privileges and read/write
access to the whole lesystem. Everything is possible with right skills !
A malicious app can spy all your activities on the phone !
A malicious app can retrieve and send your personal information to

third-parties !
Our opinion : One should use jailbreaked iPhone for personal use only if (s)he
knows how to secure the device (implicitly requires knowing all the internals !)
Security implications of Jailbreaking (2)
DEMO : An example of compromised keychain on a jailbreaked phone
A process can get access to all keychain items stored on the device.
That process requires com.apple.keystore.access-keychain-keys and

com.apple.keystore.device entitlement.
Accessing keychain-2.db directly doesnt reveal stored items keys ;

AppleKeyStore KeyUnwrap selector must be called to get stored items keys
Process must run as root

Modifying the default software stack of Android-powered
Smartphones
In Android-powered smartphones, software stack is normally modied to
get Root (privileged user) access to the phone and is known as
Rooting the phone.
Why one would like to Root the phone ?
On Android, there is no restriction on the source of apps. The only restriction

is the fact that apps can run only as non-privileged user and thereby, people
wanting their device without any restriction would go for it.
There can be a variety of motivations behind having a device without any

restricitons, for example, removing cellular restrictions, evaluating the security
and performing some malicious activities.
How do you Root Android-powered smartphone ?
If your device has an unlocked bootloader
ro.secure system property value. The value of this property is set at boot
time from default.prop le in the root directory.
And hacking one of system process running in privileged mode e.g. z4root,
gingerbreak...to execute arbitrary code (Well, the arbitrary code is normally
mounts /system in read-write mode and installs su command.)
Security implications of Rooting
If Rooted Android-powered smartphone is lost/stolen, ALL user data on

the device is at risk if adb access is enabled. Even if Android encryption
feature is ON!
Rooting normally involves ashing custom ROM and few custom ROM
builders had even removed Encryption option from the device ! It means data
is stored in the ash as plain-text !
Malicious apps can of course spy the activities on the device and steal
personal information.
Outline
1
2
3
4
5
What are we doing at present ?
We are developing a logger for iOS and Android capable of monitoring

activities all across the device especially to track access to users private
information by Apps.
iOS Logger makes use of objective-c runtime and trampoline to dynamically

analyze the applications behaviour. It runs on iPhones having modied
software stack with privileged user (root) access and disabled signature
verication of code by kernel.
Android logger modies the Android framework source code to intercept the
calls made by Apps to standard APIs. (Development in progress...late started !)
iOS Logger (1)
Our logger logs access to personal data
Contacts
Geographic location
various device and user accounts
Calendar
Photos and Videos
UDID and Device Name
Voice memos etc.
It also logs various user related activities and events (also works as
SPYWARE)
Phone calls (Incoming and outgoing)
Sending and receiving SMS, iMessage and Emails
Internet navigation using Safari/Youtube apps (Also, all raw network data
BSD SOCKETS ! Every single byte...)
Taking a picture, start/stop video capturing etc.

iOS Logger (2)
How we are doing runtime dynamic analysis ?
iOS Tweak (Trampoline + objective-c runtime)

Mobilitics app for iOS (4)
! Mobilitics tweak
! its a dynamic library (.dylib) loaded into a running process
instead of the original one
uses the MobileSubstrate framework (simplies a lot!)
22
process
original C/C++ function
or
objective-c method
calls
Tweak
(.dylib)
starts
loaded
in process
process
started

launchd

launches
loads
may call
new C/C++ function
or
objective-c method
iOS Logger Design
Three tools + Tweak (a dylib loaded at the start of each process and replaces our
implemented methods/functions with the original ones) + Preference bundle
Mobilitics app for iOS (5)
23
iOS
D
a
r
w
i
n

N
o
t
i
f
i
c
a
t
i
o
n

C
e
n
t
e
r

P
r
e
f
e
r
e
n
c
e
s

B
u
n
d
l
e

SQLite
database
Internet
LogReceiver
LogTransmitter
Tweak
LogCollector
iOS daemon
Collector
tool
Mobilitics Embedded Master package
AppSupport
Private
framework
Persistent
Connection
Private
framework
(wake up)
Questions/Discussion/Comments/Feedback
Any questions or something you want to discuss ?
Comments/feedback on the lecture ?
I recently got interested in Jailbreaking activity itself ; not merely using it. If
someone is interested ? My Email : jagdish.achara@inria.fr
THANKS

Lecture Smartphone Security

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Lecture Smartphone Security

Transféré par

Droits d'auteur :

Formats disponibles

Smartphone Security Overview

Jagdish Prasad Achara, Claude Castelluccia

Smartphone vs Feature phone ?

However, well look hardware only from security point of view

Two dierent paradigms of OSes : Android and iOS

Immutable code in Boot ROM

Bootloaders (LLB, iBoot)

iOS (XNU kernel, system modules, services, apps)

Third-party Apps downloaded and installed from Apple AppStore

a closed proprietary OS from Apple built on top of XNU kernel

The majority of iOS runs as non-privileged user mobile

The entire OS partition is mounted read-only

Remote login services arent included in the system software

Secure Boot Chain

Runtime process security by iOS kernel

J. P. Achara, C. Castelluccia (INRIA Rhone-Alpes) Smartphone Security Overview 5 decembre 2012 10 / 49

Data protection feature

Four kinds of data protection :

Data protection feature (Contd...)

Class key protects le key.

Keychain access APIs result in calls to the securityd framework.

securityd determines if a process can access a keychain item or not based on

Keychain data protection class structure

Encryption with device UID prevents restoring keychain items at another

System installs each app in its own sandbox directory

Sandbox is a set of ne-grained controls that limit access by an app to other

App Sandboxing Contd... (How it is implemented ?)

As a policy module for the TrustedBSD mandatory access control framework

sandboxd begins with calling sandbox init in libSystem > Uses

Use of entitlements for access control

Entitlements are digitally signed.

Extensively used by System Apps and daemons to perform specic privileged

Greatly reduces the potential for privilege escalation by a compromised system

Protection of memory from the exploitation of memory corruption bugs

Use of ASLR (Address Space Layout Randomization)

Memory pages marked as both writable and executable can be used by

.u - ~: ~ ~-.~., ..i~.unJ . :-~ 1u1n .r1~-:

System Software Personalization

Application Access to standard iOS APIs

However, there is no mechanism to control the way accesssed information is

Immutable code in Boot ROM

Android (Linux kernel, system modules, services, apps)

Third-party Apps (No restriction for the source !)

Linux based OS developed by Google in conjuction with Open Handset

A small amount of Android OS code runs as root.

System partition is mounted as read-only and contains Kernel, OS libraries,

Secure Boot Chain

Depends on manufacturer and also, on cellular service provider if its in

Sometimes it exists and other times it doesnt.

But unlike iPhones, it doesnt extend till Apps in any case.

is performed in the kernel using dm-crypt after Android v 3.0.

Some custom ROM builders had even removed this feature

Protection of memory from exploitation of memory corruption bugs

Latest versions use ASLR.

All installed apps must be signed

Helps in application updates

System Partition and Safe Mode

System partition contains Androids kernel, OS libraries, application runtime,

OTA or side-loaded updates.

OTA mechanism isnt described ; but with side-loaded updates downgrade is

Application Access to standard Android APIs

Application Access to standard Android APIs (Contd...)

Androids new IPC mechanisms :

Binder, Services, Intents and ContentProviders