SCE10-0496

Open Source Security Issues of

the Android Platform

A Final Year Project Report

by

Jeremy Foo Jie You

for the

School of Computer Engineering

Nanyang Technological University

under the supervision of

A/P Yow Kin Choong

for the requirements of the

Degree of Bachelor of Computer Engineering

submitted

17th October 2011

Abstract

The Android platform is fast becoming the dominant mobile operating

platform in the world, having bested the iPhone in US market share and

closing steadily on worldwide share.

By its very nature of being an open source project, the Android platform not

only raises security issues through its transparency of its source code, it also

allows for more security risks because of its open nature where developers are

given free reign and also through its un-curated distribution system in the

form of the Android Marketplace.

This project seeks to analyze these security issues, quantify them and propose

a way to mitigate these risks by either preventing them or removing them.

Research is based on the Google Nexus S running Gingerbread, version 2.3.3

based on the Linux Kernel, version 2.6.35.7.

This report quantifies this effort in dealing with the possible security issues of

the Android operating system through analysis of its security architecture,

and current work done to improve security. It also documents the proposed

solution along with a proof of concept and relevant test results for verification

of the hypothesis.

Acknowledgements

For the period of my Final Year Project (August 2010 - August 2011), I would

like to thank the following whom without, all the work that I was doing will

not be possible.

• Prof Yow for this invaluable help in procurement of hardware resources

needed for the project as well as his scrutiny, advice and direction in

helping develop the overall project from its inception to its finality.

• Ted Hsiang for his initial research work on malware on the Android

Platform which helped immensely in the development of the testbed to

verify the thesis of this very project.

• Ming Jin for assisting in the actual development of the testbed application

and input of ideas.

Table of Contents

1. List of Figures 1

Abbreviations 1

3. Introduction 2

3.1 Platform versus Operating System 3

3.2 Objectives 3

3.3 Research Details 4

3.3 Tools used 5

4. The Android Platform 6

4.1 Philosophy 6

4.2 Hardware 7

4.3 Kernel 8

4.4 Operating System 9

4.5 Third Party Development 21

5. Security Audit 24

5.1 Existing Protection 25

5.2 Attack Surface 31

5.3 Chain of Trust violation through Full Access 35

5.4 Existing Security Compromises 39

5.5 Conclusion 42

6. Securing Android 43

6.1 Philosophy 43

6.2 Existing Work 47

6.3 Mandatory Access Control 49

6.4 Hardening 51

7. Proof of Concept 56

7.1 Security Enhanced Linux 57

7.2 Patching Dalvik 58

7.3 grsecurity Patches 56

7.4 Test and Audit Tool 58

8. Conclusion 59

Recommendations 61

References 62

11. Appendix 67

11.1 Android /system/bin 67

11.2 Ubuntu /bin 69

11.3 Android Filesystem Configuration Header 71

11.4 New files added to Android Kernel 75

11.5 Sample process list using ps 78

11.6 init.rc Script 80

11.7 Sample MANIFEST.MF 86

11.8 Sample CERT.SF 87

11.9 Android Application to Test Permissions and Runtime.Exec 88

11.10 Sample netstat -a output 89

1. List of Figures

Figure 4.4.1 Android Software Stack

Figure 4.4.3.1 In depth Android Software Stack

Figure 4.4.5.1 Android Startup Flow

Figure 5.1.1 Permissions Model Hierarchy

Figure 5.1.2 Android Application Installation and Permission Request

Figure 5.1.3 BlackBerry Permissions

Figure 5.3.1 Trusted Execution Path

Figure 5.3.1.1 Nexus S Low Level Bootloader

Figure 5.3.1.2 Nexus S unlock bootloader confirmation

Open source security issues of the Android Platform

1

2. Abbreviations

AOSP Android Open Source Project

ARM Advanced RISC Machines

SoC System on a Chip

IPC Inter Process Communication

NDK Native Development Kit

SDK Software Development Kit

LSB Linux Standard Base

POSIX Portable Operating System Interface for Unix

GNU GNU is Not Unix

BSD Berkeley Software Distribution

GPL GNU General Public License

LGPL GNU Lesser General Public License

EXT4 Fourth Extended File System

YAFFS Yet Another Flash File System

ROP Return Oriented Programming

OLPC One Laptop Per Child

UID Linux User ID

GID Linux Group ID

DAC Discretionary Access Control

MAC Mandatory Access Control

ABI Application Binary Interface

ADB Android Debug Bridge

JNI Java Native Interface

XSS Cross Site Scripting

DEP Data Execution Prevention

ASLR Address Space Layout Randomization

PIC/PIE Position Independent Code/Execution

NX No eXecute

Open source security issues of the Android Platform

1

3. Introduction

In the words of Google, Android was created as an alternative to Apple’s

vision of mobile devices1. The differences between either are evident in their

philosophies towards every aspect of the platform, from its distribution,

development to even how third party applications interact with the user and

the operating system.

With Android being the alternative platform, it takes the polar opposite of

Apple’s methods, opting for an open approach to almost every aspect of their

platform versus what developers famously term, Apple’s “walled garden”.

Developers are free to use any language and tools to write their applications

in. Distribution via the Android Marketplace does not require prior review

nor curation.

While it is an absolutely delightful playground for developers, some security

concerns have been raised by companies with regards to the open source

nature of the operating systems codebase. Due to the transparency of its

source code, there are fears that malicious individuals can easily examine and

find security issues that are exploitable through the very source code

powering the platform.

Extrapolating from the open source nature of the platform, further security

concerns can be raised as developers are given free reign to do almost

anything they want, short of the permissions system that Android

implements and the permissions that the user specifies at install time.

Open source security issues of the Android Platform

2

1 Clint, B. (2010, May 2). Android vp gundotra takes gloves off vs. apple at google i/o [Web log message]. Retrieved from http://www.eweek.com/c/a/Mobile-and-Wireless/Android-VP-Gundotra-Takes-Gloves-Off-Vs-Apple-at-Google-IO-455468/

The Android project page states that the platform is a privilege separated

operating system that makes use of Application Signing, sandboxing of

applications through the use of UserIDs and Groups as well as enforcement

of permissions that the user specifies at install time.

Yet in recent reports, there has been a significant rise in Android malware

while the incumbent iOS platform does not seem to have yet suffered any

such serious security compromises that does not have a prerequisite of

“jailbreaking” the phone.

3.1 Platform versus Operating System

In referring to the Android project, there are 2 distinctions that has to be

made and reinforced. Of note, when referring to the Android platform, this

has to do with the encompassing project, its operating system, its distribution

model, basically everything to do with Android.

However, when referring to the Android Operating System, this only

encompasses the software that is providing services to the platform. As such,

this covers things like the operating system kernel, the software stack, Dalvik,

etc.

3.2 Objectives

Security research is a very broad topic that covers multiple areas of computer

science that requires cross disciplinary knowledge. This report quantifies the

work done in the research and development of creating a viable modern

security environment for the Android platform.

Included in this process is an audit of the key security features of the Android

Operating System and comparisons with its rival in the form of Apple’s iOS

platform.

3

A formulation of steps needed to be taken to improve the security mechanism

on the Android platform based on the work done in this project is also

included as a proposal for the future.

All these is needed in an attempt to answer the question of security issues

with the Android operating system, open source or otherwise, and what can

be possibly done to fix them.

3.3 Research Details

The hardware device chosen for the basis of this research is the Samsung

Nexus S. It is a Google branded Android phone which has an unlock-able

bootloader that facilitates flashing of custom firmware.

Software wise, Android 2.3.x otherwise known as Gingerbread is the status

quo along with the Linux kernel in the device that runs at version 2.6.35.7.

Relevant source code and drivers are also hosted on Android’s kernel.org git

source code repository which speeds up the process research and

development on this platform without need to hunt for extraneous drivers

and files to get the operating system working.

As the project is Linux based with modifications by Google to run their own

code, much parallels can be drawn from the Linux open source project when

it comes to dealing with the Kernel. Additionally, due to Android being an

open source project and largely developer friendly, there are numerous

forums dedicated to hacking on Android devices.

Being security research poses certain problems when it comes to references,

even more so when it comes to a platform developed by the world’s largest

internet company. As such, information from any reliable source is valuable,

4

and with the information security largely based online, there is vast

knowledge base that only exist on the internet.

3.3 Tools used

• Ubuntu Linux 11.04 as the development environment for compilation

and development for the Android platform. This is the platform that Google

has chosen as their de facto environment and thus there is some sense to

use it.

• Git for version control when it comes to development work as well as

cloning code from Google’s source code repository.

• Samsung Nexus S Specific Kernel (herring) is a Samsung Nexus S

specific kernel with modules an drivers that are provided so it can be built

specifically for the device.

• Android SDK is the development environment that is used by all Android

third party application developers and includes numerous tools to help with

development on Android devices.

• Android Open Source Project (AOSP) contains all the system files and

other things needed to create custom firmware that can be flashed onto

devices.

5

4. The Android Platform

The operating environment needs to be throughly understood before even

starting on a security audit. This includes the processes that drive the design

and development of the system, the way the software interfaces with the

hardware, down to the philosophy behind the choices made.

Originally Android was an operating system developed by Android Inc.

founded by former Danger co-founder, Andy Rubin. Eventually, Google

acquired2 the company and prepared to enter the mobile phone market with

initiatives like the Open Handset Alliance to find manufacturing partners.

As of late, Android is the lead market share holder when it comes to the

platform with iOS trailing in second place. This is largely attributed to the

numerous manufacturing licensees that they have and the general open

source nature of the project.

4.1 Philosophy

In the grand scheme of things, Google acts as the Operating System licensor

that provides the license to use the Android Operating System as well as

support for manufacturers to implement it on their devices. Google has never

seen themselves as a hardware manufacturer even putting out a call for bids3

when it comes to the manufacture of their own Google branded Nexus

phones.

Open source security issues of the Android Platform

6

2 Elgin , B. (2005, August 15). Google buys android for its mobile arsenal. Bloomberg Businessweek. Retrieved from http://www.businessweek.com/technology/content/aug2005/tc20050817_0949_tc024.htm

3 Perez, S. (2011, August 15). Google / motorola deal doesn’t guarantee a “nexus droid” [Web log message]. Retrieved from http://techcrunch.com/2011/08/15/google-motorola-deal-doesnt-guarantee-a-nexus-droid/

Even though the operating system is covered under an open source license,

use of the Google brand along with other applications that tie in with Google

services are used to enforce compliance with Google specifications for

manufacturers. This is done through a compatibility test suite, that

manufacturers have to pass4 in order to have Google allow their applications

to work on whatever device that is being tested on the test suite. Most notable

of all is the exclusion of access to the Android Marketplace should devices not

meet the compatibility definitions.

The entire Android platform contains components that are free, open source

as well proprietary. Google has made efforts to stay away from free software

licenses like GPL and LGPL as far as possible going as far as implementing

their own versions of currently existing libraries. Notable amongst these are

the Dalvik runtime as well as Bionic, a BSD licensed version of libc5.

Prior to version 3.0 of the platform the entire project was licensed under

Apache License 2.0, however versions since 3.0 have been under a closed

source model. Patches to the Linux kernel for Android still adhere to the GPL

2.0 license model.

4.2 Hardware

Google IO 2011 was where the grand vision for putting Android in as many

devices as possible was unveiled. Exercise machines, lightbulbs, media

systems were just some of the examples that the presenters were raving

7

4 Patel, N. (2011, May 12). How google controls android: digging deep into the skyhook filings [Web log message]. Retrieved from http://thisismynext.com/2011/05/12/google-android-skyhook-lawsuit-motorola-samsung/

5 Paul, R. (2009, February 23). Dream(sheep ): a developer's introduction to google android [Web log message]. Retrieved from http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-android-for-developers.ars

about6. However, the most popular devices that run Android to this day are

still mobile phones, and only recently, tablet form factor computing devices.

Being a Linux based operating system, Android is capable of running on

almost any platform that Linux supports. However, because of Google’s

concentration on mobile devices, it is highly optimized and will officially only

run on devices that have an ARM based processor7. There have been efforts to

port Android to x86 based processors but is and remains an unofficial fork of

the Android project.

Similar to any other computer system, the core components of an Android

device consist of a central processing unit which is ARM based, RAM as well

as secondary storage for the operating system. Devices also contain various

IO systems like the screen, sensors and wireless chipsets to make the device

full featured.

4.3 Kernel

In order to get Linux running according to Google’s requirements, the Linux

kernel has been forked at the 2.6.x branch and patches have been applied to

it. These patches have focus on mobile devices evident by the largest patch to

the kernel being the power management concept of wakelocks.

There has been efforts to merge the changes to the Android Linux kernel back

to the mainline but has meet with various technical challenges. These in

particular have to do with the mentioned wakelocks8 power management

8

6 GoogleDevelopers. (Producer). (2011). Google i/o 2011: keynote day one. [Web Video]. Retrieved from http://www.youtube.com/watch?v=OxzucwjFEEs

7 Vassillis, A. (2011, June 02). From zero to boot: porting android to your arm platform [Web log message]. Retrieved from http://blogs.arm.com/software-enablement/498-from-zero-to-boot-porting-android-to-your-arm-platform/

8 Corbet, J. (2009, February 10). Wakelocks and the embedded problem [Web log message]. Retrieved from http://lwn.net/Articles/318611/

locking mechanism 9, a different IPC mechanism as well as various changes to

the user/kernel space boundary.

To further complicate things, the way the source code to the Android project

is controlled by Google, allows only employees to contribute such changes to

the mainline kernel10.

Beyond the philosophical idea behind the kernel for Android, a diff of the

Samsung 2.6.35.7 Linux Kernel and the stable mainline kernel produces a diff

file of about 10MB of differences. When diff was told to ignore new files and

just concentrate on changes within the kernel sources, a much smaller 722KB

diff was produced.

On closer examination of all the number of new files11 added to the Nexus S

Linux Kernel, majority of code additions were related to platform and

hardware specific drivers for the Nexus S. These are commonly added to the

drivers directory as well as the arch directory but do not preclude the other

directories and does indicate heavy involvement from OEM partners to write

kernel code that interfaces with hardware. From code analysis, majority of

non platform specific code changes were largely made in the power directory

to support the wakelocks mechanism and additional driver support for the

binder IPC mechanism in drivers/staging/android.

4.4 Operating System

Android as an operating system can be thought of as a distribution of Linux,

with its own intricacies and structure. A more accurate description according

9

9 Corbet, J. (2009, February 18). From wakelocks to a real solution [Web log message]. Retrieved from http://lwn.net/Articles/319860/

10 Kroah-Hartman, G. (2010, December 09). Android and the linux kernel community [Web log message]. Retrieved from http://www.kroah.com/log/linux/android-kernel-problems.html

11 See Appendix “New files added to Android Kernel”

to Linux Torvalds12 is that Android is essentially a fork of the Linux project

and that perhaps sometime in the future, the gap between the mainline will

merge with the Android fork.

It is however not considered a distribution of Linux in the strictest sense if

you take into account certifying it against the Linux Foundation’s Linux

Standard Base. That being said, LSB13 is a good way to help understand the

differences and the similarities between Android and regular Linux

installations on devices. The LSB exists to standardize the software system

structure of any Linux operating system and is based on a variety of open

standards like POSIX, Single Unix Specification.

Figure 4.4.1 Android Software Stack

10

12 Vaughan-Nichols, S. J. (2011, August 18). Linus torvalds on android, the linux fork [Web log message]. Retrieved from http://www.zdnet.com/blog/open-source/linus-torvalds-on-android-the-linux-fork/9426

13 Linux standard base (lsb). (2010, April 29). Retrieved from http://www.linuxfoundation.org/collaborate/workgroups/lsb

Beyond the classification of Android, it is also important to understand the

software stack that Android uses. As shown in Figure 4.4.1, the Android

software stack gives the impression that the operating system is Linux like

but does show enough differences from traditional Linux operating systems

that sets it apart.

4.4.1 File System

Prior to even diving into the file system structure that Android uses, we first

must be aware of the different types of file systems that are mounted by the

operating system. With the help of the mount tool, we are able to see an entire

listing of the different types of file systems attached.

$ mountrootfs / rootfs ro,relatime 0 0tmpfs /dev tmpfs rw,relatime,mode=755 0 0devpts /dev/pts devpts rw,relatime,mode=600 0 0proc /proc proc rw,relatime 0 0sysfs /sys sysfs rw,relatime 0 0none /acct cgroup rw,relatime,cpuacct 0 0tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0none /dev/cpuctl cgroup rw,relatime,cpu 0 0/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0/dev/block/mtdblock6 /efs yaffs2 rw,nosuid,nodev,relatime 0 0/dev/block/platform/s3c-sdhci.0/by-name/system /system ext4 ro,relatime,barrier=1,data=ordered 0 0/dev/block/platform/s3c-sdhci.0/by-name/userdata /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0/dev/block/vold/179:3 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0/dev/block/vold/179:3 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0/dev/block/dm-0 /mnt/asec/com.rugbyworldcup.AndroidClient-1 vfat ro,dirsync,nosuid,nodev,relatime,uid=1000,fmask=0222,dmask=0222,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

Lines that are highlighted in bold list file system mount points that are of

particular interest. While the kernel exists within the ramdisk image on the

ROM, the /system mount point is where the actual operating system along

11

with its files reside. This is naturally mounted read only to provide for some

security.

The /data mount point directs to a location where all user generated data is

stored. This includes the applications the user downloads, the settings to the

various configurations of the device and even log files. Along with the /data

mount point, the /sdcard mount point behaves similarly with a focus of being

external storage that gets mounted if an SD Card exists.

An interesting thing to note is that the file system is generated in parts as

ramdisks and these are in turned flashed onto the ROM of devices or

packaged as a full firmware image14 that consists of the root, data and system

ramdisks as well as the kernel and other parts that make up Android.

Ramdisks are stored in the cpio15 file format and are compressed using the

GNU utility gzip prior to flashing onto device.

The file system structure roughly resembles that of any LSB certified Linux

distribution. With the exception of specially mounted directories like

/sdcard and OEM specific directories, the file structure contains the almost

ubiquitous directories like /dev, /etc, /mnt, /root and so on.

With the move to Android 2.3.x and as shown, Google has changed the file

system format in use to ext4. ext4 offered many advantages over YAFFS

which was previously used, most noticeable of all speed improvements16 as

12

14 Howto: unpack, edit, and re-pack boot images. In (2008). Retrieved from http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

15 http://www.gnu.org/software/cpio/

16 Peter. (2010, December 28). Android 2.3 gingerbread uses ext4 file system, promises better dual-core performance [Web log message]. Retrieved from http://blog.gsmarena.com/android-2-3-gingerbread-uses-ext4-file-system-promises-better-dual-core-performance/

well as improved support within the kernel as it was marked as stable under

the 2.6.28 source code repository.

While the upstream version of YAFFS has support for extended attributes17,

the version that is currently used by Android does not. Switching to ext4 lets

the Android operating system to gain that feature along with other

improvements.

Where the file system differs from LSB certified distributions is the lack of

certain POSIX shell and utilities. A directory listing of the /bin directory on a

copy of Ubuntu Linux and Android (located in /system/bin) shows a variety

of differences18, some which are platform specific but more importantly,

others which are needed comply with POSIX specifications which is a subset

of LSB certification is missing.

Workarounds by using BusyBox19 or installing applications that bundle and

install important POSIX utilities are a necessity if more in depth exploration

of the operating system is required.

4.4.2 Standard Libraries

Linux by default uses the GNU libc as the standard C library. While there is

an implementation of the standard C library for embedded linux systems, it is

also covered under a GNU public license - LGPL. In order to maintain the

GPL boundary at the kernel20, Google chose to rewrite the C standard library.

13

17 Smalley, S. (2011, May 11). Re: [android-kernel] froyo : ext4 instead of yaffs2 [Electronic mailing list message]. Retrieved from http://www.mail-archive.com/android-kernel@googlegroups.com/msg03101.html

18 See Appendix “Android /system/bin” vs “Ubuntu /bin”

19 Common UNIX utilities in a single executable. See www.busybox.net.

20 Cheri, Y., Schaller, A., & Wilson, G. (2007). Whitepaper: open source best practice. Retrieved from http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Whitepaper-Open-Source-Best-Practice/

In addition to preventing GPL contamination of the user space by keeping the

Bionic C library under a BSD license, the rewrite also helped in letting Google

write a version of the library that was specific to the needs of Android mobile

devices.

Bionic is a small and speedy library 21 that was specifically designed for low

clock frequencies that are seen in mobile devices. It’s size is also about 50%

smaller than glibc (GNU standard C library) as it has to be loaded into each

process.

It is not a surprise then that because of its smaller size, some POSIX features

and others that are present in glibc do not exist in Bionic. These features are

also dropped because they did not have a use on Android itself.

Consequently, Android specific support for system services exist in Bionic.

In the theme of keeping standard library small, Bionic does not use the

threading API that is implemented in glibc instead, it makes the most use of

the kernel threading features22. Keeping with the theme of excluding certain

features, some threading features were also not included, for example the

support for thread cancellation.

Apart from the C Standard Library, Android does provide other compiled

libraries for use in applications. Some of the more notable libraries include

the sqlite and the OpenGL ES libraries. These libraries are commonly stored

in the /system/lib directory and are compiled to be used as shared libraries

evident by the .so extension.

14

21 Burnette, E. (2008, June 04). Patrick brady dissects android [Web log message]. Retrieved from http://www.zdnet.com/blog/burnette/patrick-brady-dissects-android/584

22 Castet, M. (2008, November 06). android thread library ported to uclibc [Electronic mailing list message]. Retrieved from http://www.mail-archive.com/uclibc@uclibc.org/msg02787.html

4.4.3 IPC Mechanism

The Android operating provides 3 different IPC mechanisms which are used

in different situations and work at different levels of the platform.

• Linux Kernel IPC for native applications.

• Socket/New IO (NIO) available in Java.

• Binder for access to specific system services.

• DBus daemon for use by the GPL Bluetooth subsystem (Bluez).

For all intents and purposes, the only IPC system that works for Android is

Binder which provides for a way for Android applications to communicate

with system services implemented as servers as well as other components of

the applications like Android Intents. The remaining IPC mechanisms are a

by product of having components that implement or provide such IPC

mechanisms.

The Linux kernel supports the standard IPC mechanisms that Linux based

operating systems support23, namely UNIX pipes, named pipes and System V

IPC. However, due to the modifications that are made by Google to the

Android Linux Kernel, System V IPC support in the libraries (Bionic) are left

out. The standard Linux IPC mechanisms are most evident when using the

shell through the Android debug bridge. Piping output from programs to

other programs is shown to work properly by doing a process listing with a

search on the word “system_server” or ps | grep system_server.

As Android applications are first written in Java, complied into Java bytecode

and then translated into Dalvik bytecode, there has to be support for native

Java libraries. Of these, support for Java’s Socket and Native IO or New IO

15

23 Linux interprocess communications. (1996, May 29). Retrieved from http://tldp.org/LDP/lpg/node7.html

which has been around since Sun’s J2SE 1.4 release24. Consequently this has

to be built into the Dalvik VM.

Lastly, DBus support exists in a small subset as it is utilized by the GPL Bluez

Bluetooth subsystem 25. DBus communicates with the system_server via its

own DBus IPC mechanism.

Figure 4.4.3.1 In depth Android Software Stack 26

Binder is Android’s solution to the need for a way to communicate between

Dalvik processors. This is important because the root Dalvik process forks

new applications as actual Linux processes in order for enforcement of Linux

permissions via the UID/GID. This is especially important as system services

are held by the system_server process and in order to use them, Binder has

to be invoked to handle message passing to and from the other processes.

16

24 Jsr 51: new i/o apis for the javatm platform. (2002, May 09). Retrieved from http://www.jcp.org/en/jsr/detail?id=51

25 Yueh, E. (2009, June 26) Android Bluetooth Introduction retrieved from http://www.slideshare.net/erinyueh/android-bluetooth-introduction

26 Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server

Binder also provides for security by authenticate the sender and the receiver

of IPC messages ensuring that only applications with permissions to access

capabilities and information the various mangers they are requesting actually

happen. The Android Interface Definition Language is one of the ways to help

ease the development of providing an IPC interface for other application

whom you want to provide services for. Binder also exposes a device file in

the /dev directory by the name of binder.

4.4.4 Application Binary Interface

While Android applications are shipped as Java to Dex binaries, being a

operating system that uses the Linux kernel requires it to adhere to the Linux

Application Binary Interface (ABI) when it comes to binaries that are written

in native code.

jeremy@jeremy-ubuntu:/media/B9EC-1701$ file chownchown: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

Using the Android Debug Bridge (ADB) shell, the chown binary was copied

from the /system/bin directory into the /sdcard directory on the Nexus S.

The SD Card on the device was then mounted in Ubuntu Linux and the chown

binary passed to the file tool to determine what sort of file it was. As shown

from the output, the chown binary on Android is basically a Linux ELF binary

that is compiled to the ARM instruction set.

jeremy@jeremy-ubuntu:/media/B9EC-1701$ file dalvikvmdalvikvm: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

This is not isolated to POSIX utilities, Android specific servers, even the

Dalvik root process (zygote) are also ELF binaries. This further reinforces the

fact that Android is a Linux based operating system, however, the

implications of this is far reaching. Developers can technically write native

applications that compile to ARM and execute them instead of creating

libraries using the NDK and execute functions within the libraries through

17

the Java Native Interface (JNI) which allows native code to be called from

Java applications..

Building native binaries that work with Android does have a caveat.

Compiled binaries need to link to Android’s version of the standard C library

(Bionic) in order for these binaries to execute on the device. Beyond that, the

binaries are free to implement their own libraries and even use the suite of

shared libraries in the /system/lib directory to compile against.

4.4.6 The Managers

Like desktop Linux distributions, Android runs numerous servers that

provide for the different aspects of the operating system, from handling of

audio, display to security. Servers which are compiled to native binaries

largely execute out of the /system/bin directory with some exceptions from

the /sbin directory.

However, Android largely implements the rest of their servers in Java

compiled to run as components under a main Dex binary, system_server27.

This of course requires the Dalvik VM to be started prior to the system server

and thus the startup process generally starts the Dalvik root process, zygote

as early as possible to provide an environment for the other managers to

start.

Figure 4.4.3.1 lists some of the different managers that the system_server

encapsulates. Binder providers for a way to allow other applications to access

these services in a secure and authenticated manner. It is interesting to see

Google write their managers in Java while at the same time calling out to

native libraries using JNI to access the hardware itself. These managers are

typically implemented as Android Services and have their sources in the

18

27 Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server

frameworks/base/services/java/com/android/server directory of the

system source tree.

Analysis of the source code provides some insight into some of the following

managers,

• Activity Manager handles the lifecycle of Android applications from

starting to termination.

• Package Manager handles installation/removal of Android applications.

• Window Manager handles the display and general view related activity

that applications depend on including orientation and layering.

• Notification Manager deals with all the notifications that pop up and

anything related to it.

• Power Manager handles the power management of the device, whether

its on, off or locked. It uses the wakelocks mechanism.

• Location Manager handles the location gathering aspect of the device via

the various means via radio that are present on device and provides a single

point where applications can get location information that pertains to the

device.

4.4.5 Startup Process

The startup process for Android is fairly the same as any traditional Linux

distribution up to the execution of the init binary. From there on it takes on a

entirely different flow.

Examination of the init.rc script shows that the very first service that is ever

started is the ueventd daemon. This is Android’s version of the udev daemon

for Linux and has the same behavior where it manages device nodes in the

/dev directory as well as all user space actions related to removal and adding

19

of devices. This is done such that the init script can setup environment

variables and mount the file system for further booting.

Once booting is complete, the daemons are started by using the service script

to launch and maintain the daemons that are needed. In particular, the

servicemanager daemon which basically deals with management of Services

that Android applications can contain.

Figure 4.4.5.1 Android Startup Flow 28

20

28 Printemps, G. (2008, September). Deep inside android.. Presentation presented at Openexpo 2008 - zurich. Retrieved from http://www.openexpo.ch/fileadmin/documents/2008Zuerich/Slides/33_Printemps.pdf

It is after the service manager has loaded is the root Dalvik process (zygote)

started via the the app_process tool which sets up the runtime environment

and starts the application. zygote then basically takes over the duties of

launching and forking any Android application that is started, first order of

business being the start of system_server which then registers all its

managers through binder to the servicemanager daemon.

zygote is a particularly interesting process as it is the root Dalvik process that

forks and spawns the other applications that are launched. Analysis of its

code29 shows that it is expressly written in Java and make JNI callbacks to

actually fork processes. It is designed to allow a VM instance to be partially

initialized such that it can be used as the environment for new applications

that have been launched to fork with.

4.5 Third Party Development

There are 2 officially sanction ways to develop for the Android platform.

Preferred of which is the Android SDK which is a first class citizen on the

platform. This is a managed programming environment which has a runtime

that acts as a intermediary to the operating system and its services.

Recognizing that there might developers that would want to port their

applications from other platforms, Android also provides a native

development kit or NDK and provides closer access to the hardware through

the C/C++ libraries that work with the NDK.

4.5.1 Software Development Kit

The Android Software Development kit is a set of tools and libraries that

allow developers to write Android applications in Java which in turn are

compiled and converted into Dalvik runtime compatible intermediate code.

21

29 See /libcore/dalvik/src/main/java/dalvik/system/Zygote.java in the system source tree

These are usually packaged into .apk files which are zlib compressed archives

of the compiled application code as well as assets, resources and meta data.

While most Java specific libraries can be used, access to Android specific API

has to be made to the android.* name space. Google has released plugins for

Eclipse and NetBeans to aid in Android development and these IDEs are able

to help in autocompletion of code. Additionally, Google provides tools that

help in various aspects of Android development, from debugging to running

and testing applications in an emulator.

While Google encourages the use of Java for Android development, going as

far as making it a first class citizen on the platform by even writing their

services daemons using it, there are other languages that are unofficially

supported. These make use of the fact that Dalvik is pretty much a Java

Virtual Machine and any JVM compatible languages should work.

Additionally, because Dalvik is open source, a list of opcodes that it supports

can easily be found in the /libcore/dalvik/src/main/java/dalvik/

bytecode/ directory in the system source tree. It is then a trivial matter to

write a compiler that can generate an actual Dex binary that allows the Dalvik

VM to execute. A language that has preliminary support is the JVM based

Clojure30 though at this point in time is slow to execute31.

4.5.2 Native Development Kit

The Native Development Kit allows developers to create libraries in C/C++

that can be executed via the Java Native Interface (JNI) from Android

applications. This is primarily to help developers port their existing code that

are C/C++ based over to Android. The currently supported instruction sets

22

30 http://www.clojure.org

31 Gómez, D. S. (2011, February 04). Creating android applications with clojure, part 1 [Web log message]. Retrieved from http://www.deepbluelambda.org/programming/clojure/creating-android-applications-with-clojure

that the NDK complies for are the 2 ARM architecture that Android supports

as well as an x86 instruction set for execution on x86 devices.

While the libraries are compiled to native code, the execution environment

when the calling application runs still exists within the Android application

execution context. And even then, not all applications will benefit from being

in native code.

At this point in time, Android does not officially support the creation of

native binaries through the use of the NDK or any other means. It is however

possible to cross compile binaries using the tools from the system source tree

of the Android open source project as long as the final binary, should it use

standard library functions, be linked to Bionic and other dependents that are

Android specific.

It is interesting to note that Google does make extensive use of the NDK by

having their own services implement C/C++ libraries to allow access to

hardware and other aspects of the platform through JNI. Binder is an

excellent example of how IPC calls are abstracted using JNI.

23

5. Security Audit

By establishing understanding of a particular system, knowledge gained can

be reinterpreted with a security bias in order to understand what are the

security implications of the said system. Knowledge about known

vulnerabilities can also be used to further help with the analysis. For the

purposes of this discourse and to maintain context in a fast changing

landscape32 when it comes to platform releases, the target system is set at

Android version 2.3.x for the Nexus S device.

Traditionally, security analysts will look at individual components of the

system and test if there are vulnerabilities. This might include a code audit if

source code were available, or via more modern methods like fuzz testing.

Fuzz testing 33 feeds random or specially crafted data to the inputs of any

computer program and monitors for any exceptions that might be generated.

However, modern protection of computer systems and consequently more

sophisticated attacks have forced security audits to be a holistic endeavor.

Individual component vulnerability testing is important, but must also be

understood in the context of the system. Small errors in programs on their

own may no cause major issues, but used in conjunction with multiple errors

in code might give attackers a means of attacking a system. Return Oriented

Programming 34 (ROP) is one good example of such methods.

Open source security issues of the Android Platform

24

32 Garretson, R. (2010, June 04). google to ease android upgrade cycle [Web log message]. Retrieved from http://www.ciozone.com/index.php/Mobile-and-Wireless/Google-To-Ease-Android-Upgrade-Cycle.html

33 Sutton, M., Greene, A., & Amini, P. (2007). Fuzzing: brute force vulnerability discovery. Addison-Wesley.

34 Buchanan, E., Roemer, R., & Savage, S. (2008, August). Return-oriented programming: exploits without code injection. Retrieved from http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html

5.1 Existing Protection

Google explicitly states35 that security architecture of the Android platform

comprises of a privilege-separated operating system where each application

is uniquely identified. These applications can then, based on their identities,

request permissions and be granted said permissions in order to have

capabilities to execute certain processes.

What is not mentioned is that very fact that there are actually 2 permissions

models in play. Of which the more obvious is the Android application

permissions model and the lesser mentioned Linux Discretionary Access

Controls.

Linux DAC

Android Permissions Model

Android Dex Binary

Linux ELF Binary

Figure 5.1.1 Permissions Model Hierarchy

As show in Figure 5.1, the Linux DAC is the encompassing permissions model

that the the Android Permissions model has to obey. In practice, they actually

complement each other by having any Android application first respect the

Android Permissions model first for all capabilities it needs then respecting

25

35 Security and permissions. (n.d.). Retrieved from http://developer.android.com/guide/topics/security/security.html

the Linux DAC, based on the UID and GID it was assigned as a package, for

file access.

The Linux DAC is also precisely how Android “sandboxes” individual

applications through assignment of unique UID and GIDs upon installation.

5.1.1 Application Signing

All application packages are signed with a certificate that the developer holds

onto. Google does not require the certificate to be signed by a certificate

authority as the purpose of the certificate is to distinguish application

authors. As such, self signed certificates can also be used by developers.

Application signing allows Android to make certain decisions related to the

application36, chief of which is the ability to share code and data if

applications are signed using the same certificate. Additionally, application’s

can only be upgraded if the upgrade has been signed with a certificate that

matches the existing application’s certificate. Otherwise, developers will be

forced to assign a different package name and thus installs a completely new

version.

While application signing is good for verification of integrity of applications,

the lack of a trusted central certificate authority is troubling. Along with that,

the fact that developers do not need to have a private certificate maintained

with the Android Marketplace further nullifies the good that a signing

applications will do.

26

36 Signing your applications. (2011, October 03). Retrieved from http://developer.android.com/guide/publishing/app-signing.html

There are established37 ways38 to resign apk files but the gist of the whole

thing is that every apk file being a zip archive can be uncompressed. Within

this compressed archive is a META-INF directory which contains the

signature that is associated with the application. It is just a simple matter of

removing that signature and resigning the apk after modification to once

again have a valid application.

Close examination of the META-INF reveals 3 files that are tied to the

signature and certificate of the application. They are the CERT.RSA, CERT.SF39

and the MANIFEST.MF40 files corresponding to the certificate used to sign the

application, the list of SHA-1 hashes that are the signatures of the individual

files in the application package, and the manifest SHA-1 hashes respectively.

It is therefore a trivial affair to resign an existing apk after it has been

modified.

This method would be easily defeated if there is a trusted central certification

authority that the security framework can ensure the certificate is issued

from. It is understandable that because of the open nature of the operating

system, that such a system was not put in place. But it does make prudent

sense to at least have such verification functionality for proprietary

distribution systems such as the Android Marketplace.

5.1.2 User IDs and File Access

A Linux User ID is assigned to each package that is installed on the device.

This UID is unique per device and does not carry to any other devices that the

27

37 Stericson. (2009, January 16). [how to] manuals for creating a theme view single post [Online forum comment]. Retrieved from http://forum.xda-developers.com/showpost.php?p=3175518&postcount=2

38 bonsey. (2010, May 22). Java jdk,android sdk and resigning apk's [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=686341

39 See Appendix “Sample CERT.SF”

40 See Appendix “Sample MANIFEST.MF”

same user might own. Correspondingly, a group ID or GID similar to the UID

is also assigned to the package.

This allows the use of POSIX filesystem permissions to be assigned to

filesystem items and thus provide a context for the application when it is run.

Filesystem item access through APIs respect this context and “sandboxes”

applications in their own context.

Interestingly, when creating files using the MODE_PRIVATE,

MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE flags for

the official Android SDK file creation APIs, little changes are made to the

permissions associated with those files. Files still retain only permissions for

reading and writing by the owner. This leads to speculation that file access

APIs got through the Dalvik runtime’s permission checking.

Android also does not maintain a passwd or shadow file like other

distributions of Linux. Symbolic mapping of UID to users are actually done in

a header file located in the platform_system_core repository under the

android_filesystem_config.h file41. This file provides a direct 1-to-1

mapping of the different UID/GIDs that is used by filesystem image building

tools to set the correct owners and groups when creating the images that will

be flashed onto devices. In order to maintain parity with Linux filesystem

features, stubs were written as a go between for the Google developed

standard C library, Bionic. Additionally, uid and guid permissions are also set

by the init script as part of the boot phase of the operating system.

In short, the Android security model relies on the traditional Discretionary

Access Control (DAC) that Linux provides. A paper published by the National

Institute of Standards and Technology (NIST) in the United States on the

28

41 See Appendix for “Android Filesystem Configuration Header”

Assessment of Access Control Systems42 argues that the use of protection bits

in Linux DAC schemes is too coarse grained and is not able to provide fine

grained access to resources. This results in the need for the owner of the

resource to violate the principle of “least privilege” by setting protection bits

that work the best for all users of the particular resource.

The customizations to how the Linux DAC works on Android further

complicates matters. The lack of a shadow file means that as long as an su

binary exists and can be executed, the path to root access is unhindered by

passwords.

5.1.3 Permissions Enforcement

The Android permissions model enforces what extra capabilities an

application might possess beyond the ability to do computation. This is

specified at the package level through the Android manifest configuration file

and will be shown to the user at install time for approval before installation.

These permissions deal with capabilities from the ability to access the

internet (or have access to the networking stack), writing files to locations

outside the private data directories, accessing user information like their

address book or user accounts stored on system, using hardware that is

available on the device to being able to read text messages that are on the

device.

29

42 Hu., V. C., Ferraiolo, D. F., & Kuhn, D. R. National Institute of Standards and Technology, Computer Security Division. (2006). Assessment of access control systems (Interagency Report 7316). Retrieved from http://csrc.nist.gov/publications/nistir/7316/NISTIR-7316.pdf

Figure 5.1.2 Android Application Installation and Permission Request

To date, there are a staggering 117 43 different permissions that developers can

request. It is quite a feat for users who have no technical knowledge to be able

to even begin to understand what these permissions mean and how to act on

them.

With such numerous permissions, Android allows for application developers

to request a set of permissions as limited as possible in order to allow their

applications to work. While this is a valid security practice, few developers

actually follow it as it is not as convenient as requesting as broad a set as

possible.

30

43 Manifest.permission. (2011, October 03). Retrieved from http://developer.android.com/reference/android/Manifest.permission.html

Figure 5.1.2 BlackBerry Application Permissions

Additionally, while the permissions allow fine grained access to capabilities,

the approval system is disconnected from broad choice, only allowing an

application to be installed if all permissions requested are approved. There is

no fine grained control over what is actually allowed in the end, unlike

BlackBerry devices which has individual toggles for access to system

properties and capabilities.

5.2 Attack Surface

The Android attack surface is a broad one where there are multiple points of

entry for security to be compromised. At DEFCON19, a sophisticated attack

on Android devices44 was carried out that required no user interaction.

Allegedly it was done through a man-in-the-middle attack on Android devices

that got privilege escalation and thus control of the device.

Additionally, this attack was able to masquerade as the Android Marketplace

and force the upgrade of applications that were not the actual copies from the

official Android Marketplace. What is interesting about this attack is that it

made use of multiple vectors, chained them up to achieve its goal.

It still does goes to show that the Android attack surface is pretty wide.

31

44 coderman. (2011, August 2011). Def con 19 - hackers get hacked! [Electronic mailing list message]. Retrieved from http://seclists.org/fulldisclosure/2011/Aug/76

5.2.1 Android Marketplace

The Android Marketplace is a very interesting vector to attack from because

of the way it works and the ubiquity on almost all Android devices. It is

perhaps one of the most efficient forms of delivery for Android malware due

to Google’s relaxed stances towards app review.

However more sophisticated methods are available though Google has

patched vulnerabilities that have been reported. This involved the use of

Google’s own communication channels45 to Android Market servers to allow

arbitrary installation of applications. This GTalkService46 is a persistent

connection to Google servers and is the communication channel that the

Android Marketplace application uses to install applications.

It is also not difficult to imagine a scenario where a man-in-the-middle attack

occurs that masquerade as the Android Marketplace. This was suitably

demonstrated at DEFCON19 and most likely have made use of Jon

Oberheide’s research into the special commands47 that the Android

Marketplace uses to install applications.

As a sidebar, Jon also seems to have discovered a XSS vulnerability 48 in the

web version of the Android Marketplace that allows for arbitrary remote code

execution for devices though the bug since has been reported and fixed. This

32

45 Oberheide, J. (2010, May 28). When angry birds attack: android edition [Web log message]. Retrieved from http://jon.oberheide.org/blog/2011/05/28/when-angry-birds-attack-android-edition/

46 Oberheide, J. (2010, June 28). A peek inside the gtalkservice connection [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/28/a-peek-inside-the-gtalkservice-connection/

47 Oberheide, J. (2010, June 25). Remote kill and install on google android [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/

48 Oberheide, J. (2011, March 07). How i almost won pwn2own via xss [Web log message]. Retrieved from http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/

just expands the likely attack vectors that the Android Marketplace fully

presents.

Beyond what is technical, the Android Marketplace also represents a vector of

attack in the form of social engineering.

5.2.2 Dalvik

The saying you are only as strong as your weakest link applies heavily with

regards to the Dalvik attack surface. Because so many applications depend on

the VM, it is one of the single point of failure and also perhaps a good vector.

Knowing that the root Dalvik process has to have the capability to fork

Android applications as they are launched means having the process run as

root. It is then a simple matter of using what is know about Dex binaries and

opcodes to find a vulnerability such that an exploit will allow the attacking

process to take the root credentials of zygote.

Since the VM interprets bytecode, it is then a simple matter of either code

analysis to look for vulnerabilities or the more sophisticated approach of

using fuzzing49 to determine Dex binaries that will trigger exploitable bugs.

Once this exploit is found, it is just a simple matter of crafting a Dex binary

that can trigger the exploit.

5.2.3 Networking & Services

The netstat output50 from Android reveals an environment where there are

few listening services which limits attacking vectors against listening servers.

However a persistent connection to port 5228 exist which suggest strongly

33

49 Neystadt, J. (2008, February). Automated penetration testing with white-box fuzzing. Retrieved from http://msdn.microsoft.com/en-us/library/cc162782.aspx

50 See Appendix “Sample netstat -a output”

that this is the GTalkService with a IP address range ownership check as

belonging to Google to further confirm it.

Based on the attack at DEFCON19, it is possible that the attack forced the

device to connect to a compromised access point such that the operating was

forced to reconnect to the GTalkService servers. This creates an opportunity

where the attackers could route such a traffic to their own systems and thus

work the man-in-the-middle-attack in.

5.2.4 Code Execution

Without a doubt, one of the weirdest APIs that ever existed for Android

applications is the ability to call out to the shell and execute commands using

the Java API call of Runtime.getRuntime().exec(“Command”). It adds to the

bad decision that this API exists by not having an Android permission that

allows or disallows execution of such an API call.

A sample application51 was written with absolutely no permissions requested

from the user and its main aim is to see if it can find a place to write a script

as contents to a file, set it as executable and then execute it. The success of

such an application means that this alternative way of code execution would

allow a maliciously crafted kernel exploit to be packaged with an Android

application, dropped in the data directory of the application and executed,

gaining the application super user credentials to execute its payload.

Beyond this, it would also seem that it will be possible to craft a binary that

the NDK can compile that is able to make system calls to the kernel directly.

This can then be legally executed through JNI from the main Android

application.

34

51 See Appendix “11.9 Android Application to Test Permissions and Runtime.Exec”

5.2.5 Kernel Vulnerabilities

With the Linux kernel in use being a few revisions behind the mainline,

existing kernel vulnerabilities that have already been reported can still be use

in exploits. Additionally, because of the pace of updates that trickles down

from Google to its OEM partners, these exploits can still be used for a very

long time on OEM devices long after Google has patched its Google phones.

It is thus a trivial matter to use existing kernel vulnerabilities as a final stage

payload for malicious applications as these are easily available in bug

databases and sometimes with accompanying source code.

5.3 Chain of Trust violation through Full Access

While Android does not live in a jail like the iPhone, this truth goes as far as

the manufacturer of the device that the operating system is run on. In the

case of the device used as a reference in this report, there are very few

obstacles that prevent the further opening up of the device.

For OEM partners, it is a different matter entirely. The different

manufacturers implement different policies when it comes to giving

customers access to their device. Most have a secure bootloader that doesn’t

allow non signed firmware updates. But the general idea is to prevent

customers from flashing customized firmware onto their devices.

On Google’s end, they have removed the presence of the su binary in the

operating system. The su binary or superuser binary allows the invoker to set

itself as the root user of the operating system, thereby gaining super user

credentials that basically ignores all set Linux DAC policies.

35

Figure 5.3.1 Ideal Trusted Execution Path

Measures taken by OEM partners and Google ensures a pseudo trusted path

of execution for applications and services on the device through the

prevention of tampering from the lowest levels of the boot chain to the

highest level of application execution. This ensures that every component in

the execution chain are implicitly trusted and thus would execute correct and

safe applications.

Of course this runs counter to the notion that devices that run Android

should be open and thus spawn two jargons associated with gaining full

access to the device, Unlocking and Rooting. They pretty much compare to

the idea of jailbreaking iOS devices from Apple, except that on Apple devices,

it is an umbrella term.

5.3.1 Unlocking

The term unlocking comes from getting the bootloader of Android devices to

accept and flash custom firmware onto the device. This is different from the

process of removing the hardware lock that is placed by the carrier on the cell

radio of the device. While this is a simple command that can be issued to the

low level bootloader on Google phones, it is much more complicated on OEM

devices as they are locked down.

Low Level Bootloader OS Bootloader Kernel init

zygoteAndroid Application

Starts Loads Runs

Starts

Starts

36

Figure 5.3.1.1 Nexus S Low Level Bootloader

For Google phones, to unlock the bootload is simply using the Android Debug

Bridge (ADB) to boot into the bootloader itself. Once that is done, use the

fastboot tool that is available in the system source tree and issue the

command “fastboot oem unlock”. Confirm the choice and the low level

bootloader will allow you to flash any custom firmware that you may have.

37

Figure 5.3.1.2 Nexus S unlock bootloader confirmation

For OEM partners, this is a different story. The only other manufacturer that

has allowed an unlocked bootloader 52 is HTC which was announced in a

statement by their CEO on Facebook53. The most notorious of which is

Motorola which has additional protections54 to ensure that their bootloader is

not compromised. This required much work55 from the Android community

to look for an exploit that works with the bootloader such that it can be used

to allow custom firmware to be flashed onto the device ROM.

38

52 http://www.htcdev.com/bootloader

53 Chou, P. (2011, May 27). Statement from htc ceo [Facebook message]. Retrieved from https://www.facebook.com/HTC/posts/10150307320018084

54 Ziegler, C. (2010, July 16). Motorola responds to droid x bootloader controversy, says efuse isn't there to break the phone [Web log message]. Retrieved from http://www.engadget.com/2010/07/16/motorola-responds-to-droid-x-bootloader-controversy-says-efuse/

55 "cellulararrest". (2009, December 09). [droid] root instructions (updated) [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=597175

5.3.2 Rooting

Rooting is usually the next thing that comes after unlocking the bootloader as

rooting usually occurs by allow custom firmware that comes with the su

binary already installed to be flashed onto the device. This allows the users

and applications that request super user credentials56 to actually be able to

obtain the user ID of 0 or root thereby giving them permission to do anything

on the device. The method of getting root is basically the same as obtaining

super user credentials from the command line.

Once again, Google phones have the advantage when doing this because of

their unlockable low level bootloader. The su binary can be packaged as an

update and installed using the low level bootloader to flash it to the system

mount point.

OEM devices that have a protected bootloader either has to resort to exploits

on the operating system to gain root access first before writing the su binary

into the system mount point. Or they have to first unlock their bootloaders to

allow custom ROMs which already have the su binary to be flashed onto the

device.

5.4 Existing Security Compromises

Android is not spared from its fair share of security compromises. What is

particularly worrying is that the trend seems to be going upwards despite

Google and Enterprise Security companies’ best efforts to prevent such such

issues.

39

56 Rollings, M. (2010, January 17). Android: requesting root access in your app [Web log message]. Retrieved from http://www.stealthcopter.com/blog/2010/01/android-requesting-root-access-in-your-app/

Paolo Passeri, an ex Security Consultant published his list for 2011’s One Year

of Android Malware57. This list contains about 30 malware that have been

active from 2010 to 2011. The malware threat is real even though it doesn’t

seem to carry much wait in the press. Mcafee’s Threat report from the 2nd

quarter of 2011 58 also supports the notion that Android malware has had a

sharp increase.

Apart from malware, data leaks through custom applications written by

OEMs for carriers are also another interesting class of security compromises

that was not intentional.

5.4.1 Malware

While most malware is concentrated in China, two of the more interesting

ones are the DroidDream59 and Gemini60 malware. Both are trojans that have

been grafted to existing applications and re-released to pose as the actual

legitimate copy. They also exhibit botnet like behavior, calling home to

command and control servers for updates as well as new instructions in

addition to their originally intended task of which it seems is to gather private

user information.

DroidDream being the newer malware on the market also exhibits an

interesting quality of having an exploit payload (RageAgainstTheCage61) that

40

57 Passeri, P. (2011, August 11). One year of android malware (full list) [Web log message]. Retrieved from https://paulsparrows.wordpress.com/2011/08/11/one-year-of-android-malware-full-list/

58 Mcafee labs (2011). Mcafee threats report: second quarter 2011. Retrieved from http://www.mcafee.com/us/resources/reports/rp-quarterly-threat-q2-2011.pdf

59 Kevin. (2011, March 01). Update: security alert: droiddream malware found in official android market [Web log message]. Retrieved from http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/

60 Android.geinimi. (2011, January 01). Retrieved from http://www.symantec.com/security_response/writeup.jsp?docid=2011-010111-5403-99&tabid=2

61 Lineberry, A. M. (2010, August 25). Reversing latest exploid release [Web log message]. Retrieved from http://dtors.org/2010/08/25/reversing-latest-exploid-release/

was designed to help it break out of the application sandbox using a bug in

the Android Debug Bridge (ADB) and install new applications without user

intervention.

5.4.2 Info-sec data leak

Analysis of updates62 to some HTC devices have revealed a whole suite of

logging tools that collect information. While there may have been legitimate

uses for them, the implementation has been less than ideal that it would

cause a data leak. This in particular is something that Google cannot control

as this is an OEM specific issue.

The data leak in question comes about due to the way one particular logger

works. Internally, it has a service which it tries to run as root such that more

data can be logged. It also exposes a service interface on port 50240 that does

not require authentication. Any application on these HTC devices can then

get access to all the data that this logger currently works with by just

requesting access to the INTERNET permission. This makes exfiltration of

information from the logger and easy task without seeming suspicious.

Another example63 of such third party data leaks is by the VOIP application

“Skype”. A mistake in its implementation had its data directories containing

private data readable by everyone most likely caused by the

MODE_WORLD_READABLE mode. What make things worse is that these

data are unencrypted, so any application is able to read and parse Skype’s

sqlite databases.

41

62 Russakovskii, A. (2011, October 05). Massive security vulnerability in htc android devices (evo 3d, 4g, thunderbolt, others) exposes phone numbers, gps, sms, emails addresses, much more [Web log message]. Retrieved from http://www.androidpolice.com/2011/10/01/massive-security-vulnerability-in-htc-android-devices-evo-3d-4g-thunderbolt-others-exposes-phone-numbers-gps-sms-emails-addresses-much-more/

63 Case, J. (2011, April 15). [updated] exclusive: vulnerability in skype for android is exposing your name, phone number, chat logs, and a lot more [Web log message]. Retrieved from http://www.androidpolice.com/2011/04/14/exclusive-vulnerability-in-skype-for-android-is-exposing-your-name-phone-number-chat-logs-and-a-lot-more/

5.5 Conclusion

It is fairly obvious that the problem with Android was that security was never

a top priority when it came to its development. Three major revisions to the

platform has seen no improvements in the security model since its inception

while feature sets and preserving the status quo of an open platform seem to

take precedence. With such a wide attack surface open, it is a wonder why

there has not been more cases of Android devices being compromised.

42

6. Securing Android

As demonstrated, Android is quite a beast to tame. Therefore it is no surprise

that having a one size fits all solution is less likely to work than a holistic

approach that touches various parts of the operating system as well as

workflow itself.

A driving philosophy behind the securing of the platform is needed in order

to provide a clear plan of action that will improve security on the entire

platform holistically. It is then appropriate that the National Security Agency

also agrees64 on this point that there has to be a holistic plan for security on

modern operating systems.

While protecting users is the main goal of security measures, there is an

added side benefit to developers who are writing third party applications. It is

naive to think that security only affects users. By securing and protecting the

system, methods that can be used to pirate applications would become

significantly harder to implement, and consequently will help reduce piracy.

6.1 Philosophy

Mobile devices are now ubiquitous. Putting it into perspective, close to 60%

of the world population own mobile phones65 whereas only about 0.01607%

Open source security issues of the Android Platform

43

64 Loscocco, P. A., Smalley, S. D., Muckelbauer, P. A., Taylor, R. C., Turner, J. S., & Farrell, J. F. (1998, October). The inevitability of failure: the flawed assumption of security in modern computing environments. Paper presented at 21st national information systems security conference. Retrieved from http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml

65 "Personal computers (per capita) by country", World Development Indicators database. Retrieved from http://www.NationMaster.com/graph/med_per_com_percap-media-personal-computers-per-capita

own computers66. Some people who own mobile devices do not even own

computers67. It is very obvious that the security model applied to computers

does not apply to mobile devices.

A huge reason why the old security model that used to apply to computers do

not apply to mobile devices is simply because these devices are more

accessible to people who might be computer illiterate. These people do not

understand the jargon nor know that sometimes what is put up online might

be malicious.

Much inspiration was drawn from the marvelous work done by Ivan Krstić68

on the BitFrost security architecture for the OLPC project. Ivan was the

Director of Security Architecture while he was at the OLPC project69 and now

works for Apple in core security for their OS X and iOS platforms. Much of

his work is now present in the latest release of Mac OS X Lion as well as the

release of iOS 5, of which the former had plenty of accolades by security

researchers70.

The OLPC project runs each application in isolation in its own virtual

machine. It uses a customized version of Linux Vserver 71 in order to achieve

this functionality as OLPCs do not run on powerful hardware. The security

model employed also takes into consideration that the project’s source code is

44

66 "Mobile phones by country", International Telecommunication Union. Retrieved from http://www.NationMaster.com/graph/med_mob_pho-media-mobile-phones

67 Worthington, D. (2011, March 28). My mom reviews the ipad, her first computer [Web log message]. Retrieved from http://technologizer.com/2011/03/28/my-mom-reviews-the-ipad-her-first-computer/

68 http://radian.org/

69 Krstić, I. (2007). OLPC Bitfrost.Olpc. Retrieved from http://wiki.laptop.org/go/OLPC_Bitfrost

70 Fisher, D. (2011, July 21). Apple revamps security in os x lion [Web log message]. Retrieved from https://threatpost.com/en_us/blogs/apple-revamps-security-os-x-lion-072111

71 http://linux-vserver.org/

open source and does not employ security by obscurity. Additionally, security

is unobtrusive and does not get in the user’s way.

While placing processes in their individual VMs are the gold standard72 for

security like what Invisible Things Lab is doing with their Qubes73 operating

system, they are complicated to maintain and do take up significantly more

computing resources. This is not ideal on mobile devices as they already have

limited computing resources that have to be shared with applications that

run on the system.

Designing any security measures for mobile devices will have to take into

consideration the fact there will be limited computing resources to make use

of. Any security measures should philosophically be able to operate in such

conditions and be considered before implementation.

6.1.1 Users are not to be trusted

It is clearly evident from the figures that show the number of people owning

mobile phones versus computers that there will be a large number of people

who have never previously used a computer before. They have no experience

with the paradigms and jargons used when it comes to computing.

By labeling the user as a hostile entity that possibly might cause harm to the

system whether through ignorance or intentional, the security model will

effectively encompass the 2 types of people most likely to bring harm to the

system - the attacker and the ignorant.

While the principle sounds harsh, it provides for a mindset that anything

other than the system is likely to cause harm and therefore defensive

45

72 Vervloesem, K. (2010, May 05). Qubes: security by virtualization [Web log message]. Retrieved from http://lwn.net/Articles/385213/

73 http://qubes-os.org/

measures should be taken. Additionally, this principle also means that in

order to tackle ignorance, better ways of dealing with permissions must be

designed.

While the current Android permissions system is fine grained, it does require

some technical background to know what they really are about. Users should

not have to deal with this. Choice is a good thing, but ultimately everyone

only makes one - the best. It should not be a difficult task to account for

which is a good choice by reducing the number of permissions that the user

has to know about and grouping them. Additionally, permissions that are

most likely to trigger privacy concerns should be requested separately on

demand.

Additionally, instead of presenting all options available to users, the best one

should instead be weeded out and the decision made for the user. This

immediately provides an environment where the vectors are controllable

instead of having to cover all bases.

6.1.2 Prevent instead of Reacting

Most commercial security solutions for the Android platform to date rely on

signatures and reacting to security threats. This requires that updates are

made as often as possible to these solutions in order to secure the system.

While ideal, it does mean that security is reactive and might just be too late at

times to deal with new or unknown threats (0-day).

Security should be a proactive approach. It should involve writing correct

code as much as possible. Reduction in possible vectors of attack by limiting

the numbers exposed. Developing preventive measures that are all

encompassing instead of the old model of specific detection and cleaning.

46

Should closing such vectors not be ideal, implementation of low level security

measures that act as a gatekeeper is a good compromise. These act at the

basic foundation vector of any attack and shutting them down will go the long

way in preventing compromises.

6.1.3 Fix as soon as possible

Security vulnerabilities will always exist. Fixing them and releasing them as

soon as possible has to be made a priority in order to ensure that even with

all the protection that prevention offers, security compromises are hard to

come by.

Time taken to get fixes from the upstream down to OEM partners must be

improved upon and with current methods being shown as ineffective, a

rethink when approaching security fixes must be made. It is likely that

compartmentalization of common components that need security updates

and providing a mechanism that updates these independent of OEMs and

their customization might be key to such a system working.

6.2 Existing Work

There have been numerous efforts commercially to introduce security

measures to the Android operating system. The issue with these projects and

solutions are that they are rarely a holistic solution, covering on aspect while

still leaving loop holes.

6.2.1 Commercial

Every computing platform will have companies that try to provide security

solutions for and Android is no exception. Large companies like AVG

Antivirus and Symantec have a mobile version of their security suite. These

do pretty much the same job as their desktop PC components, providing

active measures against malware.

47

Smaller companies like Lookout are providing a custom suite of security

solutions that are not limited just range from detecting and removing

malware.

What is similar though is the way these solutions are delivered - as

applications on the Android Marketplace. While there is nothing wrong with

such a distribution method, these suites of application can still fall prey the

numerous malware that makes use of the social engineering vector of the

Android Marketplace by upload fake versions of these applications.

6.2.2 SELinux Android

SELinux Android or SE Android is a small project by Stephen Smalley 74 of

the NSA. It is an ambitious plan to bring SELinux to the Android platform by

patching the project to support the numerous idiosyncrasies that

differentiates the platform from traditional desktop Linux distributions.

It is pretty much still under development with only a prototype being

developed, but it does prove that such MAC systems can be implemented on

Android despite the hard work needed.

6.2.3 Android as a Hypervisor

A project out of the Fraunhofer Institute for Secure Information Technology

has produced a version of the Android operating that adheres to the goal of

isolation by virtualization.

48

74 67 Smalley, S. National Security Agency, Trust Mechanisms (R2X). (2011). The case for se android. Retrieved from http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf

Biztrust75 lets users create virtual phones within the operating system to

isolate different partitions for different uses. These partitions can have

different security policies applied to it, possibly giving the “work” partition

slightly more stringent security considerations than the “personal” partition.

It is a complete enterprise grade solution that is targeted towards businesses

that are keen on deploying Android as a corporate smartphone platform of

choice.

The only issue here is that such a solution is targeted towards businesses and

would be too impractical and complicated for use by consumers. Also, it is

not known how performance will be affected because of the virtualization of

the different virtual phones.

6.3 Mandatory Access Control

The Linux discretionary access control that Android relies on are just

sufficient for limiting access to files and directories. However, any modern

techniques of privilege escalation can easily defeat such permissions based

system by simply gaining root.

It has been successfully implemented on iOS and as a testament to its

effectiveness, has suffered no malware attacks despite its huge number of OS

vulnerabilities76.

49

75 UNGERLEIDER, N. (2011, October 10). The most secure android phone, ever [Web log message]. Retrieved from http://www.fastcompany.com/1786472/most-secure-android-phone-ever-blackberry-headache?partner=gnews

76 Nachenberg, C. (2011). A window into mobile device security. Retrieved from http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_security_june2011.pdf?om_ext_cid=biz_socmed_twitter_facebook_marketwire_linkedin_2011Jun_worldwide_mobilesecuritywp

6.3.1 Operating System

Using discretionary access controls as a means of sandboxing has been

proven time and time again on the Android platform as not sufficient. There

has to be a partnership with MAC security policies in order to ensure that

security policies are actually effective and fine grained.

These access controls should work as close to the kernel as possible,

preferably loaded as a kernel module. This allows for good performance when

applying security policies as well as being close enough to bare metal that it is

the single point where these policies can be enforced.

Various MAC systems were evaluated but most promising were those that

supported Linux Security Modules (LSM). Of which, NSA’s SELinux 77 stood

out the most78 due to its flexibility and capability at handling complex

security policies. It also does MAC at the inode level of the filesystem instead

of directory based which prevents hard linking attacks. SELinux is also what

TrustedBSD79 is based upon which has been ported and adapted for Apple’s

Mac OS X operating system and more successfully implemented on their iOS

devices.

Having SELinux support easily enabled within Android’s Linux kernel

through compile options made it the best choice for a MAC system for

Android.

50

77 http://selinuxproject.org/

78 Smalley, S. National Security Agency, Trust Mechanisms (R2X). (2011). The case for se android. Retrieved from http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf

79 http://www.trustedbsd.org

6.3.2 Dalvik

However, because majority of applications are written in Java, compiled and

executed in the Dalvik environment, patches must be made to the Dalvik VM

to support these access control mechanisms through the labeling of resources

as well as the application itself. This is where the extended attributes of the

file system will come into play.

Additionally, the VM itself could be placed under a sandbox to prevent it

from becoming a possible attack vector should a maliciously crafted Dex

binary be started.

6.4 Hardening

Another aspect of improving security by preventing or reducing possible

attack vectors is the act of hardening a system against vulnerabilities. These

bugs may still exist, but the system itself makes it really difficult to exploit

and be useful to any malicious attacker.

6.4.1 Patching

The most basic of all is to constantly patch vulnerabilities by keeping

software updates. This is not limited to the kernel which is important, but

also every component along the trusted execution path.

Of course special attention should be paid to the Linux kernel as this is one of

Android’s weakest links due to its age. Patching its bugs is one thing, but

more importantly preventive measures should be taken to mitigate the

possibility that attacks can occur. For a long time, desktop Linux has had the

luxury of having grsecurity80 patches for the Linux kernel, so it is a fairly

obvious choice to include it for Android as well.

51

80 http://www.grsecurity.net

grsecurty is a bunch of patches to the Linux kernel that hardens it against

attacks. Things like ensuring proper functions that deal with overrun buffers

or compiling the kernel with more secure options are part and parcel of the

grsecurity package. These patches basically add special compile options to

allow system administrators to define security policies that effectively reflect

the principle of “least privilege”.

Additionally, the set of patches are also include the work done by the PaX81

project which are basically exploit mitigation techniques82 that further serve

to harden the operating system against attacks.

6.4.2 Reduce Vectors

Reduction of vectors involve making processes that are likely to be attacked

more benign. This can include a variety of methods of which setting proper

and appropriate UID bits is one of them. An audit of the functions of long

running services or system specific tools will give a clearer understanding as

to the sort of permissions that is needed. From there, MAC or even simple

DAC permissions setting can be applied.

One good example is the Bonjour daemon on Mac OS X. It is currently

sandboxed on the OS such that it only has the privilege to deal with network

connections and nothing more. It doesn’t have access to files and directories

so attacks against it to try to access files are mitigated. This is a proper

reduction of attack vectors.

Reduction of vectors can also come about by reducing the possible tools

malicious attacks can use to attack the system. Google has done something of

that sort by removing the su binary, however that is not enough. Closing

52

81 http://pax.grsecurity.net/

82 More explained in ASLR and DEP

vectors like the ability to execute commands on the shell makes the removal

of the su binary all the more effective.

6.4.3 Data Execution Prevention

Android devices currently ship with ARM designs as a processor package. It

is however a wonder why to this date the hardware based Data Execution

Prevention (DEP) features of these ARM chips are not put into use. Apple’s

iOS uses it to great effect to prevent arbitrary code execution as a result of

exploits that target gaining control of the program counter of the CPU.

DEP basically lets the operating system mark memory pages as either read-

write-noexec or read-exec, the core principle being memory which is

designated as data should not be allowed to execute, and memory that

contains program code should be allowed to read and execute but not write.

This prevents exploit techniques to rewrite the program code via overruns to

gain control of the program counter.

grsecurity includes patches from the PaX project83 that explicitly deals with

this problem. Additionally, should any CPU not support such features, PaX is

also able to emulate DEP such that operating systems can still take advantage

of the protection that DEP offers.

6.4.4 Address Space Layout Randomization

DEP with Address Space Layout Randomization (ASLR) is as good as useless.

Exploit techniques like return orientated programming’s84 return-to-libc

53

83 http://pax.grsecurity.net/docs/

84 Kane, D. (2009, August 11). Computer scientists take over electronic voting machine with new programming technique [Web log message]. Retrieved from http://www.sciencedaily.com/releases/2009/08/090810161902.htm

attacks85 basically defeat DEP by using pieces of other binaries that are

already in memory (most notably the standard C library) to form opcodes

that correspond to system calls to control the program counter once again.

This attack only works if the location of where the standard C library is

loaded in memory is know whether through discovery or because it is always

located at the same spot in memory. ASLR defeats this attack by randomizing

where libraries are loaded at load time. In fact, the entire address space is

randomized such that it is almost impossible to predict where a library may

be loaded.

grsecurity’s use of PaX is perhaps the most complete implementation of

ASLR, going as far as to even doing ASLR on the kernel stack. This provides

the most entropy as almost the entire memory space is randomize. As a

caveat, this requires binaries to be compiled with position independent code

(PIC) which will allow these binaries to be loaded anywhere in memory

without problems.

6.4.5 Using existing protections properly

Much more can be done to further protect the operating system from

tampering beyond implementing the measures presented above. This

involves the proper usage of protection mechanisms that come with Linux.

While it is understandable that Google needed a optimized version of Linux

that would work on mobile devices, changing large portions of the code base

including rewriting the way file system permissions are implemented

introduces the risk that such code is not mature.

The mantra that less code is better for the programmer always holds as this

means less chance for errors. The Linux kernel and Linux as an operating

54

85 c0ntex. (n.d.). Bypassing non-executable-stack during exploitation using return-to-libc [Electronic mailing list message]. Retrieved from http://www.infosecwriters.com/text_resources/pdf/return-to-libc.pdf

system has had many years to mature its code base along with multiple

talented individuals working on it. It would be folly to try to rewrite certain

implementations and expect error free code considering the small team that

Android has86.

As mentioned previously under the security audit, getting permissions right

is also important. Closing loopholes like allowing shell execution access87 via

the Java API without purview by the Dalvik permissions model should also

rate highly in getting existing protections working properly.

55

86 Vaughan-Nichols, S. J. (2010, September 07). Android/linux kernel fight continues [Web log message]. Retrieved from http://blogs.computerworld.com/16900/android_linux_kernel_fight_continues

87 See 5.2.4 Code Execution

7. Proof of Concept

In the course of research and audits, some work was made towards a proof of

concept that a holistic approach to security on Android is a viable method

that would help in the mitigation of security compromises. This largely

involved work in Android’s Linux kernel as well as experiments in getting a

customized firmware to work. A simple test tool was also developed as a

benchmark to determine of the proof of concept worked.

This is still largely a work in progress as the amount of knowledge needed to

tackle these specific areas far exceed what is capable in the period of the

project.

7.1 grsecurity Patches

The grsecurity patches were chosen as the first component in the holistic

approach to security because they represented the best of breed to exploit

mitigation techniques on the Linux kernel. Also because they seemed the mos

straightforward to apply. The only problem was that there have been no prior

work in this area to get grsecurity working on Android. Understandably so

because of the numerous differences between the Android kernel and the

mainline Linux kernel that grsecurity was designed for.

Initial work with grsecurity on Android largely dealt with looking for the

specific patch that worked with the Nexus S’ 2.6.35.7 version of the Linux

kernel. While the main site does not contain anything beyond the stable

version of the kernel, the particular patch that was designed for Android’s

kernel was found on a mirror88 that held test versions of grsecurity. Test

Open source security issues of the Android Platform

56

88 http://mirrors.muarf.org/grsecurity/test/

versions are typically versions that exist because they are high in version

number than the stable version that grsecurity officially supports.

Getting the kernel patched and compile successfully was largely an exercise

in using the diff and manually applying some code changes manually to the

power management code in Linux because of the wakelocks mechanism.

However, upon applying the kernel image to the device, it failed to boot.

Likely theories as to why this is happening range from the unique standard C

library that the kernel cross compiles with to the fact that there are certain

compile options that grsecurity modifies that doesn’t let the kernel boot.

More time and more understanding into kernel development is need to find

fruition in this area.

7.2 Security Enhanced LinuxWith the amount of work put in by Stephen Smalley, it was an obvious choice

to use SELinux as MAC system for the proof of concept. The kernel support

for SELinux also tipped the decision in its favor.

Initial work to get SELinux compiled into the kernel and booting was met

with little resistance. However, with no reference to work with apart from a

conceptual understanding of how it was supposed to happen, modification of

the operating system to support SELinux has been difficult.

Successes were mostly made with getting it to run via the init.rc script and

setting policies on certain directories. Getting SELinux to work with the

Binder IPC mechanism required some knowledge into Binder and how

SELinux can integrate into Binder.

More work is needed in this area to get SELinux fully working properly.

57

7.3 Patching Dalvik

Based on the limited success with SELinux, work was turned to looking at the

possibility of patching the Dalvik VM to label applications as they were

forked. This was a fairly straight forward process which necessitated the need

to look through the Dalvik VM’s code to look for an entry point to add code to

set SELinux security contexts for apps.

More work can be done to match security contexts to Dalvik permissions

such that there is more consistent protection across the board.

7.4 Test and Audit Tool

The test and audit tool is basically a Android application that requests as little

permissions as possible and progressively through different means tries to

achieve super user access. This tool has evolved out of the original sample

application89 that tests to see if shell execution was able to be done without

need for permissions along with writing to a directory without permissions.

Additionally, for further enhances the testing tool, exploits were packaged

with the application and were executed in turn as alternative means of getting

super user access. A utility to test kernel system calls was also included to

ensure that there were no system calls that were blocked in a similar fashion

as Apple’s iOS.

Comparison between stock versions of Android and a partially SELinux

protected version of Android were made using the tool and results do show

that SELinux does offer some protection despite its infancy on Android.

58

89 See Appendix “11.9 Android Application to Test Permissions and Runtime.Exec”

8. Conclusion

It is unfortunate that the topics that security deals with especially in systems

and architecture design is so cross disciplinary, broad while being in-depth at

the same time for this to be easily concluded.

It is without a doubt that Android has its security issues. This does not just

stem from that fact that the platform is open source. Google’s policy and

philosophy towards their rapid platform growth with a small team in order to

catch up with Apple’s iOS devices comes at the cost of security.

While there are already security solutions on the market, this discourse and

real world examples prove that they are not enough to secure a platform that

will be used by many, most of which are not technically savvy. There is a need

for a holistic look towards security in general and sometimes looking at the

competitor platform for ideas does not hurt.

Others my detract and say that by implementing policies from a closed

system will destroy the open nature of the platform, it is worth a shot as these

policies are no different from those that can already be found on Linux

desktop distributions that also have open policies towards code.

In fact, it is the open source nature of Android that lets numerous security

solutions be experimented upon and code to be audited. The work by the NSA

and many others to improve the security of Android would not be possible if

the Android source code is there for anyone to tinker with.

However all these solutions are only as good as Google actually implementing

them. And while having numerous solutions are good, there has to be

standardization when it comes to security such that a proper policy that will

Open source security issues of the Android Platform

59

cater to the mass market can be designed. Security should not be complex as

it only creates more problems.

A call to action for OEM devices partners and custom ROM developers is

need to get everyone to start wanting to implement good security for Android

devices. And that call to action must be followed by an easy to implement and

genuinely intuitive and user accessible design.

Android has the potential to be one of the most secure operating systems on

the planet, but that would need the help of everyone in the Android

community. Otherwise, these open source security issues will still persist.

60

9. Recommendations

Just like BizTrust, there is a viable option in developing this idea of a holistic

security platform for Android much further. While BizTrust targets the

enterprise market, there is a larger one in the consumer space.

More should be done into looking at Mandatory Access Control on Linux.

Supporting the work to get SELinux on Android is a good start. In addition to

that, finding a way to map the security permissions that Dalvik requires to

the SELinux security context in an unobtrusive manner as much as possible

should be a top priority such that it is easy to integrate this system.

grsecurity is an untapped resource and should be full adapted to work for

Android. This would mean understanding the Linux kernel, grsecurity and

how it can be applied to the Android modified kernel. The tradeoffs however

are immeasurable due to the exploit mitigation techniques it provides.

Tools if not better tools to help administer these security features for users is

also another area to look towards to making this solution as holistic as

possible.

Open source security issues of the Android Platform

61

10. References

Clint, B. (2010, May 2). Android vp gundotra takes gloves off vs. apple at google i/o [Web log message]. Retrieved from http://www.eweek.com/c/a/Mobile-and-Wireless/Android-VP-Gundotra-Takes-Gloves-Off-Vs-Apple-at-Google-IO-455468/

Elgin , B. (2005, August 15). Google buys android for its mobile arsenal. Bloomberg Businessweek. Retrieved from http://www.businessweek.com/technology/content/aug2005/tc20050817_0949_tc024.htm

Perez, S. (2011, August 15). Google / motorola deal doesn’t guarantee a “nexus droid” [Web log message]. Retrieved from http://techcrunch.com/2011/08/15/google-motorola-deal-doesnt-guarantee-a-nexus-droid/

Patel, N. (2011, May 12). How google controls android: digging deep into the skyhook filings [Web log message]. Retrieved from http://thisismynext.com/2011/05/12/google-android-skyhook-lawsuit-motorola-samsung/

Paul, R. (2009, February 23). Dream(sheep ): a developer's introduction to google android [Web log message]. Retrieved from http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-android-for-developers.ars

GoogleDevelopers. (Producer). (2011). Google i/o 2011: keynote day one. [Web Video]. Retrieved from http://www.youtube.com/watch?v=OxzucwjFEEs

Vassillis, A. (2011, June 02). From zero to boot: porting android to your arm platform [Web log message]. Retrieved from http://blogs.arm.com/software-enablement/498-from-zero-to-boot-porting-android-to-your-arm-platform/

Corbet, J. (2009, February 10). Wakelocks and the embedded problem [Web log message]. Retrieved from http://lwn.net/Articles/318611/

Corbet, J. (2009, February 18). From wakelocks to a real solution [Web log message]. Retrieved from http://lwn.net/Articles/319860/

Kroah-Hartman, G. (2010, December 09). Android and the linux kernel community [Web log message]. Retrieved from http://www.kroah.com/log/linux/android-kernel-problems.html

Vaughan-Nichols, S. J. (2011, August 18). Linus torvalds on android, the linux fork [Web log message]. Retrieved from http://www.zdnet.com/blog/open-source/linus-torvalds-on-android-the-linux-fork/9426

Linux standard base (lsb). (2010, April 29). Retrieved from http://www.linuxfoundation.org/collaborate/workgroups/lsb

Howto: unpack, edit, and re-pack boot images. In (2008). Retrieved from http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images

http://www.gnu.org/software/cpio/

Peter. (2010, December 28). Android 2.3 gingerbread uses ext4 file system, promises better dual-core performance [Web log message]. Retrieved from http://blog.gsmarena.com/android-2-3-gingerbread-uses-ext4-file-system-promises-better-dual-core-performance/

Smalley, S. (2011, May 11). Re: [android-kernel] froyo : ext4 instead of yaffs2 [Electronic mailing list message]. Retrieved

Open source security issues of the Android Platform

62

from http://www.mail-archive.com/android-kernel@googlegroups.com/msg03101.html

http://www.busybox.net

Cheri, Y., Schaller, A., & Wilson, G. (2007). Whitepaper: open source best practice. Retrieved from http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Whitepaper-Open-Source-Best-Practice/

Burnette, E. (2008, June 04). Patrick brady dissects android [Web log message]. Retrieved from http://www.zdnet.com/blog/burnette/patrick-brady-dissects-android/584

Castet, M. (2008, November 06). android thread library ported to uclibc [Electronic mailing list message]. Retrieved from http://www.mail-archive.com/uclibc@uclibc.org/msg02787.html

Linux interprocess communications. (1996, May 29). Retrieved from http://tldp.org/LDP/lpg/node7.html

Jsr 51: new i/o apis for the javatm platform. (2002, May 09). Retrieved from http://www.jcp.org/en/jsr/detail?id=51

Yueh, E. (2009, June 26) Android Bluetooth Introduction retrieved from http://www.slideshare.net/erinyueh/android-bluetooth-introduction

Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server

Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server

Printemps, G. (2008, September). Deep inside android.. Presentation presented at Openexpo 2008 - zurich. Retrieved from http://www.openexpo.ch/fileadmin/documents/2008Zuerich/Slides/33_Printemps.pdf

http://www.clojure.org

Gómez, D. S. (2011, February 04). Creating android applications with clojure, part 1 [Web log message]. Retrieved from http://www.deepbluelambda.org/programming/clojure/creating-android-applications-with-clojure

Garretson, R. (2010, June 04). google to ease android upgrade cycle [Web log message]. Retrieved from http://www.ciozone.com/index.php/Mobile-and-Wireless/Google-To-Ease-Android-Upgrade-Cycle.html

Sutton, M., Greene, A., & Amini, P. (2007). Fuzzing: brute force vulnerability discovery. Addison-Wesley.

Buchanan, E., Roemer, R., & Savage, S. (2008, August). Return-oriented programming: exploits without code injection. Retrieved from http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html

Security and permissions. (n.d.). Retrieved from http://developer.android.com/guide/topics/security/security.html

Signing your applications. (2011, October 03). Retrieved from http://developer.android.com/guide/publishing/app-signing.html

Stericson. (2009, January 16). [how to] manuals for creating a theme view single post [Online forum comment]. Retrieved

63

from http://forum.xda-developers.com/showpost.php?p=3175518&postcount=2

bonsey. (2010, May 22). Java jdk,android sdk and resigning apk's [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=686341

Hu., V. C., Ferraiolo, D. F., & Kuhn, D. R. National Institute of Standards and Technology, Computer Security Division. (2006). Assessment of access control systems (Interagency Report 7316). Retrieved from http://csrc.nist.gov/publications/nistir/7316/NISTIR-7316.pdf

Manifest.permission. (2011, October 03). Retrieved from http://developer.android.com/reference/android/Manifest.permission.html

coderman. (2011, August 2011). Def con 19 - hackers get hacked! [Electronic mailing list message]. Retrieved from http://seclists.org/fulldisclosure/2011/Aug/76

Oberheide, J. (2010, May 28). When angry birds attack: android edition [Web log message]. Retrieved from http://jon.oberheide.org/blog/2011/05/28/when-angry-birds-attack-android-edition/

Oberheide, J. (2010, June 28). A peek inside the gtalkservice connection [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/28/a-peek-inside-the-gtalkservice-connection/

Oberheide, J. (2010, June 25). Remote kill and install on google android [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/

Oberheide, J. (2011, March 07). How i almost won pwn2own via xss [Web log message]. Retrieved from http://

jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/

Neystadt, J. (2008, February). Automated penetration testing with white-box fuzzing. Retrieved from http://msdn.microsoft.com/en-us/library/cc162782.aspx

http://www.htcdev.com/bootloader

Chou, P. (2011, May 27). Statement from htc ceo [Facebook message]. Retrieved from https://www.facebook.com/HTC/posts/10150307320018084

Ziegler, C. (2010, July 16). Motorola responds to droid x bootloader controversy, says efuse isn't there to break the phone [Web log message]. Retrieved from http://www.engadget.com/2010/07/16/motorola-responds-to-droid-x-bootloader-controversy-says-efuse/

"cellulararrest". (2009, December 09). [droid] root instructions (updated) [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=597175

Rollings, M. (2010, January 17). Android: requesting root access in your app [Web log message]. Retrieved from http://www.stealthcopter.com/blog/2010/01/android-requesting-root-access-in-your-app/

Passeri, P. (2011, August 11). One year of android malware (full list) [Web log message]. Retrieved from https://paulsparrows.wordpress.com/2011/08/11/one-year-of-android-malware-full-list/

Mcafee labs (2011). Mcafee threats report: second quarter 2011. Retrieved from http://www.mcafee.com/us/resources/reports/rp-quarterly-threat-q2-2011.pdf

64

Kevin. (2011, March 01). Update: security alert: droiddream malware found in official android market [Web log message]. Retrieved from http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/

Android.geinimi. (2011, January 01). Retrieved from http://www.symantec.com/security_response/writeup.jsp?docid=2011-010111-5403-99&tabid=2

Lineberry, A. M. (2010, August 25). Reversing latest exploid release [Web log message]. Retrieved from http://dtors.org/2010/08/25/reversing-latest-exploid-release/

Russakovskii, A. (2011, October 05). Massive security vulnerability in htc android devices (evo 3d, 4g, thunderbolt, others) exposes phone numbers, gps, sms, emails addresses, much more [Web log message]. Retrieved from http://www.androidpolice.com/2011/10/01/massive-security-vulnerability-in-htc-android-devices-evo-3d-4g-thunderbolt-others-exposes-phone-numbers-gps-sms-emails-addresses-much-more/

Case, J. (2011, April 15). [updated] exclusive: vulnerability in skype for android is exposing your name, phone number, chat logs, and a lot more [Web log message]. Retrieved from http://www.androidpolice.com/2011/04/14/exclusive-vulnerability-in-skype-for-android-is-exposing-your-name-phone-number-chat-logs-and-a-lot-more/

Loscocco, P. A., Smalley, S. D., Muckelbauer, P. A., Taylor, R. C., Turner, J. S., & Farrell, J. F. (1998, October). The inevitability of failure: the flawed assumption of security in modern computing environments. Paper presented at 21st national information systems security conference. Retrieved from http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml

"Personal computers (per capita) by country", World Development Indicators database. Retrieved from http://www.NationMaster.com/graph/med_per_com_percap-media-personal-computers-per-capita

"Mobile phones by country", International Telecommunication Union. Retrieved from http://www.NationMaster.com/graph/med_mob_pho-media-mobile-phones

Worthington, D. (2011, March 28). My mom reviews the ipad, her first computer [Web log message]. Retrieved from http://technologizer.com/2011/03/28/my-mom-reviews-the-ipad-her-first-computer/

http://radian.org/

Krstić, I. (2007). OLPC Bitfrost.Olpc. Retrieved from http://wiki.laptop.org/go/OLPC_Bitfrost

Fisher, D. (2011, July 21). Apple revamps security in os x lion [Web log message]. Retrieved from https://threatpost.com/en_us/blogs/apple-revamps-security-os-x-lion-072111

http://linux-vserver.org/

Vervloesem, K. (2010, May 05). Qubes: security by virtualization [Web log message]. Retrieved from http://lwn.net/Articles/385213/

http://qubes-os.org/

Smalley, S. National Security Agency, Trust Mechanisms (R2X). (2011). The case for se android. Retrieved from http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf

65

UNGERLEIDER, N. (2011, October 10). The most secure android phone, ever [Web log message]. Retrieved from http://www.fastcompany.com/1786472/most-secure-android-phone-ever-blackberry-headache?partner=gnews

Nachenberg, C. (2011). A window into mobile device security. Retrieved from http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_security_june2011.pdf?om_ext_cid=biz_socmed_twitter_facebook_marketwire_linkedin_2011Jun_worldwide_mobilesecuritywp

http://selinuxproject.org/

http://www.trustedbsd.org

http://www.grsecurity.net

http://pax.grsecurity.net/

http://pax.grsecurity.net/docs/

Kane, D. (2009, August 11). Computer scientists take over electronic voting machine with new programming technique [Web log message]. Retrieved from http://www.sciencedaily.com/releases/2009/08/090810161902.htm

c0ntex. (n.d.). Bypassing non-executable-stack during exploitation using return-to-libc [Electronic mailing list message]. Retrieved from http://www.infosecwriters.com/text_resources/pdf/return-to-libc.pdf

Vaughan-Nichols, S. J. (2010, September 07). Android/linux kernel fight continues [Web log message]. Retrieved from http://blogs.computerworld.com/16900/android_linux_kernel_fight_continues

http://mirrors.muarf.org/

grsecurity/test/

66

11. Appendix

11.1 Android /system/bin

# ls -l-rwxr-xr-x root shell 191 2010-11-25 05:42 am-rwxr-xr-x root shell 5720 2010-11-25 05:42 app_process-rwxr-xr-x root shell 49924 2011-05-04 02:10 applypatch-rwxr-xr-x root shell 5292 2010-11-25 05:42 bluetoothd-rwxr-xr-x root shell 199 2010-11-25 05:42 bmgr-rwxr-xr-x root shell 23160 2010-11-25 05:42 bootanimation-rwxr-xr-x root shell 10116 2010-11-25 05:42 brcm_patchram_plus-rwxr-xr-x root shell 5556 2010-11-25 05:42 bugreportlrwxr-xr-x root shell 2010-11-30 07:30 cat -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 chmod -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 chown -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 cmp -> toolbox-rwxr-xr-x root shell 5520 2011-05-04 02:10 dalvikvmlrwxr-xr-x root shell 2010-11-30 07:30 date -> toolbox-rwxr-xr-x root shell 109504 2011-05-04 02:10 dbus-daemonlrwxr-xr-x root shell 2010-11-30 07:30 dd -> toolbox-rwxr-xr-x root shell 18112 2011-05-04 02:10 debuggerd-rwxr-xr-x root shell 9796 2011-05-04 02:10 dexoptlrwxr-xr-x root shell 2010-11-30 07:30 df -> toolbox-rwxr-xr-x root shell 44596 2011-05-04 02:10 dhcpcdlrwxr-xr-x root shell 2010-11-30 07:30 dmesg -> toolbox-rwxr-xr-x root shell 108820 2011-05-04 02:10 dnsmasq-rwxr-xr-x root shell 34544 2010-11-25 05:42 dumpstate-rwxr-xr-x root shell 9812 2010-11-25 05:42 dumpsys-rwxr-xr-x root shell 5548 2010-11-25 05:42 dvz-rwxr-xr-x root shell 22640 2011-05-04 02:10 fsck_msdoslrwxr-xr-x root shell 2010-11-30 07:30 getevent -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 getprop -> toolbox-rwxr-xr-x root shell 5604 2011-05-04 02:10 gzip-rwxr-xr-x root shell 23284 2011-05-04 02:10 hciattachlrwxr-xr-x root shell 2010-11-30 07:30 hd -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 id -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 ifconfig -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 iftop -> toolbox-rwxr-xr-x root shell 194 2010-11-25 05:42 ime-rwxr-xr-x root shell 201 2010-11-25 05:42 inputlrwxr-xr-x root shell 2010-11-30 07:30 insmod -> toolbox-rwxr-xr-x root shell 22420 2011-05-04 02:10 installdlrwxr-xr-x root shell 2010-11-30 07:30 ioctl -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 ionice -> toolbox-rwxr-xr-x root shell 100916 2011-05-04 02:10 iptables-rwxr-xr-x root shell 10112 2011-05-04 02:10 keystorelrwxr-xr-x root shell 2010-11-30 07:30 kill -> toolbox-rwxr-xr-x root shell 39416 2011-05-04 02:10 linkerlrwxr-xr-x root shell 2010-11-30 07:30 ln -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 log -> toolbox-rwxr-xr-x root shell 13952 2011-05-04 02:10 logcat-rwxr-xr-x root shell 9760 2011-05-04 02:10 logwrapperlrwxr-xr-x root shell 2010-11-30 07:30 ls -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 lsmod -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 lsof -> toolbox-rwxr-xr-x root shell 5504 2010-11-25 05:42 make_ext4fs-rwxr-xr-x root shell 5488 2010-11-25 05:42 mediaserverlrwxr-xr-x root shell 2010-11-30 07:30 mkdir -> toolbox-rwxr-xr-x root shell 205 2010-11-25 05:42 monkeylrwxr-xr-x root shell 2010-11-30 07:30 mount -> toolbox-rwxr-xr-x root shell 18308 2011-05-04 02:10 mtpdlrwxr-xr-x root shell 2010-11-30 07:30 mv -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 nandread -> toolbox-rwxr-xr-x root shell 5552 2010-11-25 05:42 ndc-rwxr-s--- root inet 5660 2011-05-04 02:10 netcfg-rwxr-xr-x root shell 31172 2011-05-04 02:10 netd

Open source security issues of the Android Platform

67

lrwxr-xr-x root shell 2010-11-30 07:30 netstat -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 newfs_msdos -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 notify -> toolbox-rwxr-xr-x root shell 32600 2011-05-04 02:10 omx_tests-rwxr-xr-x root shell 18692 2010-11-25 05:42 pand-rwxr-sr-x root net_raw 26720 2011-05-04 02:10 ping-rwxr-xr-x root shell 191 2010-11-25 05:42 pm-rwxr-xr-x root shell 139540 2011-05-04 02:10 pppdlrwxr-xr-x root shell 2010-11-30 07:30 printenv -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 ps -> toolbox-rwxr-xr-x root shell 142516 2011-05-04 02:10 racoonlrwxr-xr-x root shell 2010-11-30 07:30 reboot -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 renice -> toolbox-rwxr-xr-x root shell 9808 2011-05-04 02:10 rildlrwxr-xr-x root shell 2010-11-30 07:30 rm -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 rmdir -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 rmmod -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 route -> toolbox-rwsr-s--- root shell 59848 2011-05-04 02:10 run-as-rwxr-xr-x root shell 5392 2010-11-25 05:42 schedtestlrwxr-xr-x root shell 2010-11-30 07:30 schedtop -> toolbox-rwxr-xr-x root shell 9748 2010-11-25 05:42 sdcard-rwxr-xr-x root shell 42404 2010-11-25 05:42 sdptoollrwxr-xr-x root shell 2010-11-30 07:30 sendevent -> toolbox-rwxr-xr-x root shell 9860 2010-11-25 05:42 service-rwxr-xr-x root shell 9940 2011-05-04 02:10 servicemanagerlrwxr-xr-x root shell 2010-11-30 07:30 setconsole -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 setprop -> toolbox-rwxr-xr-x root shell 5564 2010-11-25 05:42 setup_fs-rwxr-xr-x root shell 82840 2011-05-04 02:10 shlrwxr-xr-x root shell 2010-11-30 07:30 sleep -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 smd -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 start -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 stop -> toolbox-rwxr-xr-x root shell 5456 2011-05-04 02:10 surfaceflinger-rwxr-xr-x root shell 192 2010-11-25 05:42 svclrwxr-xr-x root shell 2010-11-30 07:30 sync -> toolbox-rwxr-xr-x root shell 5472 2010-11-25 05:42 system_server-rwxr-xr-x root shell 67956 2011-05-04 02:10 tc-rwxr-xr-x root shell 81544 2011-05-04 02:10 toolboxlrwxr-xr-x root shell 2010-11-30 07:30 top -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 umount -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 uptime -> toolbox-rwxr-xr-x root shell 5552 2010-11-25 05:42 vdclrwxr-xr-x root shell 2010-11-30 07:30 vmstat -> toolbox-rwxr-xr-x root shell 51700 2011-05-04 02:10 voldlrwxr-xr-x root shell 2010-11-30 07:30 watchprops -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 wipe -> toolbox-rwxr-xr-x root shell 291876 2011-05-04 02:10 wpa_supplicant-rwsr-sr-x root root 22228 2011-09-29 21:16 su-rwxr-xr-x root shell 24120 2011-03-23 19:51 sqlite3drwxrwxrwx root root 2011-09-29 21:40 failsafe

68

11.2 Ubuntu /bin

jeremy@jeremy-ubuntu:/bin$ ls -ltotal 8108-rwxr-xr-x 1 root root 954896 2011-04-01 05:20 bash-rwxr-xr-x 1 root root 31112 2011-02-21 00:13 bunzip2-rwxr-xr-x 1 root root 1964728 2011-02-23 11:30 busybox-rwxr-xr-x 1 root root 31112 2011-02-21 00:13 bzcatlrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzcmp -> bzdiff-rwxr-xr-x 1 root root 2140 2011-02-21 00:13 bzdifflrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzegrep -> bzgrep-rwxr-xr-x 1 root root 4874 2011-02-21 00:13 bzexelrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzfgrep -> bzgrep-rwxr-xr-x 1 root root 3642 2011-02-21 00:13 bzgrep-rwxr-xr-x 1 root root 31112 2011-02-21 00:13 bzip2-rwxr-xr-x 1 root root 10336 2011-02-21 00:13 bzip2recoverlrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzless -> bzmore-rwxr-xr-x 1 root root 1297 2011-02-21 00:13 bzmore-rwxr-xr-x 1 root root 47696 2011-02-23 22:24 cat-rwxr-xr-x 1 root root 55864 2011-02-23 22:24 chgrp-rwxr-xr-x 1 root root 51704 2011-02-23 22:24 chmod-rwxr-xr-x 1 root root 55880 2011-02-23 22:24 chown-rwxr-xr-x 1 root root 10392 2011-03-18 07:47 chvt-rwxr-xr-x 1 root root 117808 2011-02-23 22:24 cp-rwxr-xr-x 1 root root 137232 2011-02-24 01:49 cpio-rwxr-xr-x 1 root root 109736 2010-11-15 16:34 dash-rwxr-xr-x 1 root root 55832 2011-02-23 22:24 date-rwxr-xr-x 1 root root 10464 2011-07-23 01:05 dbus-cleanup-sockets-rwxr-xr-x 1 root root 351448 2011-07-23 01:05 dbus-daemon-rwxr-xr-x 1 root root 10376 2011-07-23 01:05 dbus-uuidgen-rwxr-xr-x 1 root root 51840 2011-02-23 22:24 dd-rwxr-xr-x 1 root root 64208 2011-02-23 22:24 df-rwxr-xr-x 1 root root 105776 2011-02-23 22:24 dir-rwxr-xr-x 1 root root 10368 2011-03-21 16:28 dmesg-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 dnsdomainname-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 domainname-rwxr-xr-x 1 root root 82152 2011-03-18 07:47 dumpkeys-rwxr-xr-x 1 root root 26968 2011-02-23 22:24 echo-rwxr-xr-x 1 root root 47552 2010-10-30 00:45 ed-rwxr-xr-x 1 root root 126240 2010-11-18 12:09 egrep-rwxr-xr-x 1 root root 22856 2011-02-23 22:24 false-rwxr-xr-x 1 root root 10408 2011-03-18 07:47 fgconsole-rwxr-xr-x 1 root root 85088 2010-11-18 12:09 fgrep-rwxr-xr-x 1 root root 31680 2010-10-16 00:47 fuser-rwsr-xr-x 1 root root 31320 2011-02-11 05:03 fusermount-rwxr-xr-x 1 root root 126272 2010-11-18 12:09 grep-rwxr-xr-x 1 root root 63 2010-08-17 16:43 gunzip-rwxr-xr-x 1 root root 5874 2010-08-17 16:43 gzexe-rwxr-xr-x 1 root root 64168 2010-08-17 16:43 gzip-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 hostname-rwxr-xr-x 1 root root 5564 2011-04-21 06:56 init-checkconf-rwxr-xr-x 1 root root 16005 2011-04-21 06:56 initctl2dot-rwxr-xr-x 1 root root 234768 2010-10-15 20:45 ip-rwxr-xr-x 1 root root 10400 2011-03-18 07:47 kbd_mode-rwxr-xr-x 1 root root 18736 2011-04-07 23:36 kill-rwxr-xr-x 1 root root 149496 2009-11-05 16:52 less-rwxr-xr-x 1 root root 10504 2009-11-05 16:52 lessecholrwxrwxrwx 1 root root 8 2011-07-31 02:47 lessfile -> lesspipe-rwxr-xr-x 1 root root 15840 2009-11-05 16:52 lesskey-rwxr-xr-x 1 root root 6947 2009-11-05 16:51 lesspipe-rwxr-xr-x 1 root root 47680 2011-02-23 22:24 ln-rwxr-xr-x 1 root root 111288 2011-03-18 07:47 loadkeys-rwxr-xr-x 1 root root 44928 2011-02-21 08:18 login-rwxr-xr-x 1 root root 57000 2010-09-16 08:23 lowntfs-3g-rwxr-xr-x 1 root root 105776 2011-02-23 22:24 ls-rwxr-xr-x 1 root root 6088 2011-04-01 22:05 lsmod-rwxr-xr-x 1 root root 47624 2011-02-23 22:24 mkdir-rwxr-xr-x 1 root root 31112 2011-02-23 22:24 mknod-rwxr-xr-x 1 root root 35352 2011-02-23 22:24 mktemp-rwxr-xr-x 1 root root 35448 2011-03-21 16:28 more-rwsr-xr-x 1 root root 82224 2011-03-21 16:28 mount-rwxr-xr-x 1 root root 10264 2011-03-29 04:21 mountpoint

69

lrwxrwxrwx 1 root root 20 2011-07-31 02:47 mt -> /etc/alternatives/mt-rwxr-xr-x 1 root root 68712 2011-02-24 01:49 mt-gnu-rwxr-xr-x 1 root root 109584 2011-02-23 22:24 mv-rwxr-xr-x 1 root root 191960 2010-12-04 04:32 nanolrwxrwxrwx 1 root root 20 2011-07-31 02:47 nc -> /etc/alternatives/nc-rwxr-xr-x 1 root root 31152 2011-01-05 04:23 nc.openbsdlrwxrwxrwx 1 root root 24 2011-07-31 02:47 netcat -> /etc/alternatives/netcat-rwxr-xr-x 1 root root 120184 2010-07-02 15:28 netstat-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 nisdomainname-rwxr-xr-x 1 root root 52800 2010-09-16 08:23 ntfs-3g-rwxr-xr-x 1 root root 10368 2010-09-16 08:23 ntfs-3g.probe-rwxr-xr-x 1 root root 55816 2010-09-16 08:23 ntfs-3g.secaudit-rwxr-xr-x 1 root root 14576 2010-09-16 08:23 ntfs-3g.usermaplrwxrwxrwx 1 root root 6 2011-07-31 02:47 open -> openvt-rwxr-xr-x 1 root root 14688 2011-03-18 07:47 openvtlrwxrwxrwx 1 root root 14 2011-07-31 02:47 pidof -> /sbin/killall5-rwsr-xr-x 1 root root 35680 2010-11-15 16:11 ping-rwsr-xr-x 1 root root 40248 2010-11-15 16:11 ping6-rwxr-xr-x 1 root root 35360 2011-04-27 05:31 plymouth-rwxr-xr-x 1 root root 31560 2011-04-27 05:31 plymouth-upstart-bridge-rwxr-xr-x 1 root root 101184 2011-04-07 23:36 ps-rwxr-xr-x 1 root root 31200 2011-02-23 22:24 pwdlrwxrwxrwx 1 root root 4 2011-07-31 02:47 rbash -> bash-rwxr-xr-x 1 root root 35272 2011-02-23 22:24 readlink-rwxr-xr-x 1 root root 55872 2011-02-23 22:24 rm-rwxr-xr-x 1 root root 39320 2011-02-23 22:24 rmdirlrwxrwxrwx 1 root root 4 2011-07-31 02:47 rnano -> nano-rwxr-xr-x 1 root root 15048 2011-01-20 23:44 run-parts-rwxr-xr-x 1 root root 69024 2010-11-16 18:14 sed-rwxr-xr-x 1 root root 39744 2011-03-18 07:47 setfont-rwxr-xr-x 1 root root 12052 2011-04-21 01:02 setupconlrwxrwxrwx 1 root root 4 2011-07-31 02:47 sh -> dashlrwxrwxrwx 1 root root 4 2011-07-31 02:47 sh.distrib -> bash-rwxr-xr-x 1 root root 26984 2011-02-23 22:24 sleeplrwxrwxrwx 1 root root 7 2011-07-31 02:47 static-sh -> busybox-rwxr-xr-x 1 root root 63992 2011-02-23 22:24 stty-rwsr-xr-x 1 root root 36832 2011-02-21 08:18 su-rwxr-xr-x 1 root root 22872 2011-02-23 22:24 sync-rwxr-xr-x 1 root root 10488 2011-03-21 16:28 tailf-rwxr-xr-x 1 root root 311888 2010-12-07 18:10 tar-rwxr-xr-x 1 root root 10312 2011-01-20 23:44 tempfile-rwxr-xr-x 1 root root 47640 2011-02-23 22:24 touch-rwxr-xr-x 1 root root 22856 2011-02-23 22:24 true-rwxr-xr-x 1 root root 14656 2011-02-11 05:03 ulockmgr_server-rwsr-xr-x 1 root root 56616 2011-03-21 16:28 umount-rwxr-xr-x 1 root root 27016 2011-02-23 22:24 uname-rwxr-xr-x 1 root root 63 2010-08-17 16:43 uncompress-rwxr-xr-x 1 root root 2762 2011-03-18 07:47 unicode_start-rwxr-xr-x 1 root root 105776 2011-02-23 22:24 vdir-rwxr-xr-x 1 root root 6200 2011-02-23 23:58 vmmouse_detect-rwxr-xr-x 1 root root 946 2011-01-20 23:44 which-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 ypdomainname-rwxr-xr-x 1 root root 64 2010-08-17 16:43 zcat-rwxr-xr-x 1 root root 69 2010-08-17 16:43 zcmp-rwxr-xr-x 1 root root 4424 2010-08-17 16:43 zdiff-rwxr-xr-x 1 root root 64 2010-08-17 16:43 zegrep-rwxr-xr-x 1 root root 64 2010-08-17 16:43 zfgrep-rwxr-xr-x 1 root root 2015 2010-08-17 16:43 zforce-rwxr-xr-x 1 root root 5597 2010-08-17 16:43 zgrep-rwxr-xr-x 1 root root 1733 2010-08-17 16:43 zless-rwxr-xr-x 1 root root 2416 2010-08-17 16:43 zmore-rwxr-xr-x 1 root root 4952 2010-08-17 16:43 znew

70

11.3 Android Filesystem Configuration Header

/* * Copyright (C) 2007 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */

/* This file is used to define the properties of the filesystem** images generated by build tools (mkbootfs and mkyaffs2image) and** by the device side of adb.*/

#ifndef _ANDROID_FILESYSTEM_CONFIG_H_#define _ANDROID_FILESYSTEM_CONFIG_H_

#include <string.h>#include <sys/stat.h>#include <sys/types.h>

/* This is the master Users and Groups config for the platform.** DO NOT EVER RENUMBER.*/

#define AID_ROOT 0 /* traditional unix root user */

#define AID_SYSTEM 1000 /* system server */

#define AID_RADIO 1001 /* telephony subsystem, RIL */#define AID_BLUETOOTH 1002 /* bluetooth subsystem */#define AID_GRAPHICS 1003 /* graphics devices */#define AID_INPUT 1004 /* input devices */#define AID_AUDIO 1005 /* audio devices */#define AID_CAMERA 1006 /* camera devices */#define AID_LOG 1007 /* log devices */#define AID_COMPASS 1008 /* compass device */#define AID_MOUNT 1009 /* mountd socket */#define AID_WIFI 1010 /* wifi subsystem */#define AID_ADB 1011 /* android debug bridge (adbd) */#define AID_INSTALL 1012 /* group for installing packages */#define AID_MEDIA 1013 /* mediaserver process */#define AID_DHCP 1014 /* dhcp client */#define AID_SDCARD_RW 1015 /* external storage write access */#define AID_VPN 1016 /* vpn system */#define AID_KEYSTORE 1017 /* keystore subsystem */#define AID_USB 1018 /* USB devices */#define AID_DRM 1019 /* DRM server */#define AID_DRMIO 1020 /* DRM IO server */#define AID_GPS 1021 /* GPS daemon */#define AID_UNUSED1 1022 /* deprecated, DO NOT USE */#define AID_RFU1 1023 /* RFU */#define AID_RFU2 1024 /* RFU */#define AID_NFC 1025 /* nfc subsystem */

#define AID_SHELL 2000 /* adb and debug shell user */#define AID_CACHE 2001 /* cache access */#define AID_DIAG 2002 /* access to diagnostic resources */

/* The 3000 series are intended for use as supplemental group id's only. * They indicate special Android capabilities that the kernel is aware of. */#define AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */#define AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap sockets */

71

#define AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */#define AID_NET_RAW 3004 /* can create raw INET sockets */#define AID_NET_ADMIN 3005 /* can configure interfaces and routing tables. */

#define AID_MISC 9998 /* access to misc storage */#define AID_NOBODY 9999

#define AID_APP 10000 /* first app user */

#if !defined(EXCLUDE_FS_CONFIG_STRUCTURES)struct android_id_info { const char *name; unsigned aid;};

static const struct android_id_info android_ids[] = { { "root", AID_ROOT, }, { "system", AID_SYSTEM, }, { "radio", AID_RADIO, }, { "bluetooth", AID_BLUETOOTH, }, { "graphics", AID_GRAPHICS, }, { "input", AID_INPUT, }, { "audio", AID_AUDIO, }, { "camera", AID_CAMERA, }, { "log", AID_LOG, }, { "compass", AID_COMPASS, }, { "mount", AID_MOUNT, }, { "wifi", AID_WIFI, }, { "dhcp", AID_DHCP, }, { "adb", AID_ADB, }, { "install", AID_INSTALL, }, { "media", AID_MEDIA, }, { "drm", AID_DRM, }, { "drmio", AID_DRMIO, }, { "nfc", AID_NFC, }, { "shell", AID_SHELL, }, { "cache", AID_CACHE, }, { "diag", AID_DIAG, }, { "net_bt_admin", AID_NET_BT_ADMIN, }, { "net_bt", AID_NET_BT, }, { "sdcard_rw", AID_SDCARD_RW, }, { "vpn", AID_VPN, }, { "keystore", AID_KEYSTORE, }, { "usb", AID_USB, }, { "gps", AID_GPS, }, { "inet", AID_INET, }, { "net_raw", AID_NET_RAW, }, { "net_admin", AID_NET_ADMIN, }, { "misc", AID_MISC, }, { "nobody", AID_NOBODY, },};

#define android_id_count \ (sizeof(android_ids) / sizeof(android_ids[0])) struct fs_path_config { unsigned mode; unsigned uid; unsigned gid; const char *prefix;};

/* Rules for directories.** These rules are applied based on "first match", so they** should start with the most specific path and work their** way up to the root.*/

static struct fs_path_config android_dirs[] = { { 00770, AID_SYSTEM, AID_CACHE, "cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/app" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/app-private" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/dalvik-cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/data" },

72

{ 00771, AID_SHELL, AID_SHELL, "data/local/tmp" }, { 00771, AID_SHELL, AID_SHELL, "data/local" }, { 01771, AID_SYSTEM, AID_MISC, "data/misc" }, { 00770, AID_DHCP, AID_DHCP, "data/misc/dhcp" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data" }, { 00750, AID_ROOT, AID_SHELL, "sbin" }, { 00755, AID_ROOT, AID_SHELL, "system/bin" }, { 00755, AID_ROOT, AID_SHELL, "system/vendor" }, { 00755, AID_ROOT, AID_SHELL, "system/xbin" }, { 00755, AID_ROOT, AID_ROOT, "system/etc/ppp" }, { 00777, AID_ROOT, AID_ROOT, "sdcard" }, { 00755, AID_ROOT, AID_ROOT, 0 },};

/* Rules for files.** These rules are applied based on "first match", so they** should start with the most specific path and work their** way up to the root. Prefixes ending in * denotes wildcard** and will allow partial matches.*/static struct fs_path_config android_files[] = { { 00440, AID_ROOT, AID_SHELL, "system/etc/init.goldfish.rc" }, { 00550, AID_ROOT, AID_SHELL, "system/etc/init.goldfish.sh" }, { 00440, AID_ROOT, AID_SHELL, "system/etc/init.trout.rc" }, { 00550, AID_ROOT, AID_SHELL, "system/etc/init.ril" }, { 00550, AID_ROOT, AID_SHELL, "system/etc/init.testmenu" }, { 00550, AID_DHCP, AID_SHELL, "system/etc/dhcpcd/dhcpcd-run-hooks" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/dbus.conf" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/bluetooth/main.conf" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/bluetooth/input.conf" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/bluetooth/audio.conf" }, { 00444, AID_NET_BT, AID_NET_BT, "system/etc/bluetooth/blacklist.conf" }, { 00640, AID_SYSTEM, AID_SYSTEM, "system/etc/bluetooth/auto_pairing.conf" }, { 00444, AID_RADIO, AID_AUDIO, "system/etc/AudioPara4.csv" }, { 00555, AID_ROOT, AID_ROOT, "system/etc/ppp/*" }, { 00555, AID_ROOT, AID_ROOT, "system/etc/rc.*" }, { 00644, AID_SYSTEM, AID_SYSTEM, "data/app/*" }, { 00644, AID_SYSTEM, AID_SYSTEM, "data/app-private/*" }, { 00644, AID_APP, AID_APP, "data/data/*" }, /* the following two files are INTENTIONALLY set-gid and not set-uid. * Do not change. */ { 02755, AID_ROOT, AID_NET_RAW, "system/bin/ping" }, { 02750, AID_ROOT, AID_INET, "system/bin/netcfg" }, !/* the following five files are INTENTIONALLY set-uid, but they! * are NOT included on user builds. */ { 06755, AID_ROOT, AID_ROOT, "system/xbin/su" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/librank" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/procrank" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/procmem" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/tcpdump" }, { 04770, AID_ROOT, AID_RADIO, "system/bin/pppd-ril" },!!/* the following file is INTENTIONALLY set-uid, and IS included!! * in user builds. */ { 06750, AID_ROOT, AID_SHELL, "system/bin/run-as" }, { 00755, AID_ROOT, AID_SHELL, "system/bin/*" }, { 00755, AID_ROOT, AID_SHELL, "system/xbin/*" }, { 00755, AID_ROOT, AID_SHELL, "system/vendor/bin/*" }, { 00750, AID_ROOT, AID_SHELL, "sbin/*" }, { 00755, AID_ROOT, AID_ROOT, "bin/*" }, { 00750, AID_ROOT, AID_SHELL, "init*" }, { 00644, AID_ROOT, AID_ROOT, 0 },};

static inline void fs_config(const char *path, int dir, unsigned *uid, unsigned *gid, unsigned *mode){ struct fs_path_config *pc; int plen; pc = dir ? android_dirs : android_files; plen = strlen(path); for(; pc->prefix; pc++){ int len = strlen(pc->prefix);

73

if (dir) { if(plen < len) continue; if(!strncmp(pc->prefix, path, len)) break; continue; } /* If name ends in * then allow partial matches. */ if (pc->prefix[len -1] == '*') { if(!strncmp(pc->prefix, path, len - 1)) break; } else if (plen == len){ if(!strncmp(pc->prefix, path, len)) break; } } *uid = pc->uid; *gid = pc->gid; *mode = (*mode & (~07777)) | pc->mode; #if 0 fprintf(stderr,"< '%s' '%s' %d %d %o >\n", path, pc->prefix ? pc->prefix : "", *uid, *gid, *mode);#endif}#endif#endif

74

11.4 New files added to Android Kernel

jeremy@jeremy-ubuntu:~$ diff -rq linux-stable samsung | grep "Only in"Only in samsung/Documentation: android.txtOnly in samsung/arch/arm/common: fiq_debugger.cOnly in samsung/arch/arm/common: fiq_debugger_ringbuf.hOnly in samsung/arch/arm/common: fiq_glue.SOnly in samsung/arch/arm/common: fiq_glue_setup.cOnly in samsung/arch/arm/configs: herring_defconfigOnly in samsung/arch/arm/include/asm: fiq_debugger.hOnly in samsung/arch/arm/include/asm: fiq_glue.hOnly in samsung/arch/arm/mach-s5pv210: adc.cOnly in samsung/arch/arm/mach-s5pv210: coresight.cOnly in samsung/arch/arm/mach-s5pv210: cpu-freq.cOnly in samsung/arch/arm/mach-s5pv210: cpuidle.cOnly in samsung/arch/arm/mach-s5pv210: dev-cpufreq.cOnly in samsung/arch/arm/mach-s5pv210: dev-fiqdbg.cOnly in samsung/arch/arm/mach-s5pv210: dev-herring-phone.cOnly in samsung/arch/arm/mach-s5pv210: herring-btlpm.cOnly in samsung/arch/arm/mach-s5pv210: herring-panel.cOnly in samsung/arch/arm/mach-s5pv210: herring-rfkill.cOnly in samsung/arch/arm/mach-s5pv210: herring-touchkey-led.cOnly in samsung/arch/arm/mach-s5pv210: herring-vibrator.cOnly in samsung/arch/arm/mach-s5pv210: herring-watchdog.cOnly in samsung/arch/arm/mach-s5pv210: herring.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: adc.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: battery.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: cpu-freq-v210.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: gpio-herring.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: media.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: param.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: pm-core.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: power-domain.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: regs-adc.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: regs-audss.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: regs-mem.hOnly in samsung/arch/arm/mach-s5pv210: mach-herring.cOnly in samsung/arch/arm/mach-s5pv210: pm.cOnly in samsung/arch/arm/mach-s5pv210: power-domain.cOnly in samsung/arch/arm/mach-s5pv210: setup-csis.cOnly in samsung/arch/arm/mach-s5pv210: setup-fb.cOnly in samsung/arch/arm/mach-s5pv210: setup-fimc0.cOnly in samsung/arch/arm/mach-s5pv210: setup-fimc1.cOnly in samsung/arch/arm/mach-s5pv210: setup-fimc2.cOnly in samsung/arch/arm/mach-s5pv210: sleep.SOnly in samsung/arch/arm/plat-s5p: bootmem.cOnly in samsung/arch/arm/plat-s5p: dev-csis.cOnly in samsung/arch/arm/plat-s5p: dev-mfc.cOnly in samsung/arch/arm/plat-s5p: devs.cOnly in samsung/arch/arm/plat-s5p: hr-time-rtc.cOnly in samsung/arch/arm/plat-s5p/include/plat: csis.hOnly in samsung/arch/arm/plat-s5p/include/plat: fb.hOnly in samsung/arch/arm/plat-s5p/include/plat: fimc.hOnly in samsung/arch/arm/plat-s5p/include/plat: irq-eint-group.hOnly in samsung/arch/arm/plat-s5p/include/plat: irq-pm.hOnly in samsung/arch/arm/plat-s5p/include/plat: jpeg.hOnly in samsung/arch/arm/plat-s5p/include/plat: media.hOnly in samsung/arch/arm/plat-s5p/include/plat: mfc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-csis.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-fb.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-fimc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-iis.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-ipc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-keypad.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-mfc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-systimer.hOnly in samsung/arch/arm/plat-s5p: irq-eint-group.cOnly in samsung/arch/arm/plat-s5p: irq-pm.cOnly in samsung/arch/arm/plat-s5p: pm.cOnly in samsung/arch/arm/plat-s5p: setup-mfc.cOnly in samsung/arch/arm/plat-s5p: systimer-s5p.cOnly in samsung/arch/arm/plat-samsung: dev-hsmmc3.c

75

Only in samsung/arch/arm/plat-samsung/include/plat: regs-otg.hOnly in samsung/drivers/char: dcc_tty.cOnly in samsung/drivers/char: s3c_mem.cOnly in samsung/drivers/char: s3c_mem.hOnly in samsung/drivers/gpu: pvrOnly in samsung/drivers/input/keyboard: cypress-touchkey-firmware.cOnly in samsung/drivers/input/keyboard: cypress-touchkey-firmware.hOnly in samsung/drivers/input/keyboard: cypress-touchkey.cOnly in samsung/drivers/input: keyreset.cOnly in samsung/drivers/input/misc: gp2a.cOnly in samsung/drivers/input/misc: gpio_axis.cOnly in samsung/drivers/input/misc: gpio_event.cOnly in samsung/drivers/input/misc: gpio_input.cOnly in samsung/drivers/input/misc: gpio_matrix.cOnly in samsung/drivers/input/misc: gpio_output.cOnly in samsung/drivers/input/misc: k3g.cOnly in samsung/drivers/input/misc: keychord.cOnly in samsung/drivers/input/touchscreen: mxt224.cOnly in samsung/drivers/input/touchscreen: synaptics_i2c_rmi.cOnly in samsung/drivers/leds: ledtrig-sleep.cOnly in samsung/drivers/media/video: s5k4ecgx.cOnly in samsung/drivers/media/video: s5k4ecgx_regs_1_0.hOnly in samsung/drivers/media/video: s5k4ecgx_regs_1_1.hOnly in samsung/drivers/media/video: s5ka3dfx.cOnly in samsung/drivers/media/video: s5ka3dfx.hOnly in samsung/drivers/media/video: samsungOnly in samsung/drivers/mfd: max8998.cOnly in samsung/drivers/misc: ak8973-reg.hOnly in samsung/drivers/misc: ak8973.cOnly in samsung/drivers/misc: akm8975.cOnly in samsung/drivers/misc: apanic.cOnly in samsung/drivers/misc: fsa9480.cOnly in samsung/drivers/misc: kernel_debugger.cOnly in samsung/drivers/misc: kr3dm.cOnly in samsung/drivers/misc: kr3dm_reg.hOnly in samsung/drivers/misc: pmem.cOnly in samsung/drivers/misc: pn544.cOnly in samsung/drivers/misc: samsung_modemctlOnly in samsung/drivers/misc: sec_jack.cOnly in samsung/drivers/misc: uid_stat.cOnly in samsung/drivers/misc: wl127x-rfkill.cOnly in samsung/drivers/net: pppolac.cOnly in samsung/drivers/net: pppopns.cOnly in samsung/drivers/net/wimax: cmc7xxOnly in samsung/drivers/net/wireless: bcm4329Only in samsung/drivers/power: fuel_gauge.cOnly in samsung/drivers/power: s3c_fake_battery.cOnly in samsung/drivers/power: s5pc110_battery.cOnly in samsung/drivers/power: s5pc110_battery.hOnly in samsung/drivers/regulator: max8893.cOnly in samsung/drivers/regulator: max8998.cOnly in samsung/drivers/rtc: alarm-dev.cOnly in samsung/drivers/rtc: alarm.cOnly in samsung/drivers/rtc: rtc-max8998.cOnly in samsung/drivers/rtc: rtc-s3c.hOnly in samsung/drivers/staging: androidOnly in samsung/drivers: switchOnly in samsung/drivers/usb/gadget: android.cOnly in samsung/drivers/usb/gadget: f_accessory.cOnly in samsung/drivers/usb/gadget: f_adb.cOnly in samsung/drivers/usb/gadget: f_mtp.cOnly in samsung/drivers/usb/gadget: s3c_udc.hOnly in samsung/drivers/usb/gadget: s3c_udc_otg.cOnly in samsung/drivers/usb/gadget: s3c_udc_otg_xfer_dma.cOnly in samsung/drivers/video: samsungOnly in samsung/firmware: samsung_mfc_fw.bin.ihexOnly in samsung/fs: yaffs2Only in samsung/include/linux: akm8975.hOnly in samsung/include/linux: android_aid.hOnly in samsung/include/linux: android_alarm.hOnly in samsung/include/linux: android_pmem.hOnly in samsung/include/linux: ashmem.hOnly in samsung/include/linux: cpuacct.hOnly in samsung/include/linux: earlysuspend.h

76

Only in samsung/include/linux: fsa9480.hOnly in samsung/include/linux: gp2a.hOnly in samsung/include/linux: gpio_event.hOnly in samsung/include/linux/i2c: ak8973.hOnly in samsung/include/linux: if_pppolac.hOnly in samsung/include/linux: if_pppopns.hOnly in samsung/include/linux/input: cypress-touchkey.hOnly in samsung/include/linux/input: k3g.hOnly in samsung/include/linux/input: mxt224.hOnly in samsung/include/linux: kernel_debugger.hOnly in samsung/include/linux: keychord.hOnly in samsung/include/linux: keyreset.hOnly in samsung/include/linux: kr3dm.hOnly in samsung/include/linux/mfd: max8998-private.hOnly in samsung/include/linux/mfd: max8998.hOnly in samsung/include/linux/mfd/wm8994: wm8994_pdata.hOnly in samsung/include/linux: nt35580.hOnly in samsung/include/linux: pn544.hOnly in samsung/include/linux/regulator: max8893.hOnly in samsung/include/linux: sec_jack.hOnly in samsung/include/linux: switch.hOnly in samsung/include/linux: synaptics_i2c_rmi.hOnly in samsung/include/linux: tl2796.hOnly in samsung/include/linux: uid_stat.hOnly in samsung/include/linux/usb: android_composite.hOnly in samsung/include/linux/usb: f_accessory.hOnly in samsung/include/linux/usb: f_mtp.hOnly in samsung/include/linux: videodev2_samsung.hOnly in samsung/include/linux: wakelock.hOnly in samsung/include/linux: wifi_tiwlan.hOnly in samsung/include/linux/wimax: samsungOnly in samsung/include/linux: wl127x-rfkill.hOnly in samsung/include/linux: wlan_plat.hOnly in samsung/include/media: s5k4ecgx.hOnly in samsung/include/media: s5ka3dfx_platform.hOnly in samsung/include/net: activity_stats.hOnly in samsung/kernel/power: consoleearlysuspend.cOnly in samsung/kernel/power: earlysuspend.cOnly in samsung/kernel/power: fbearlysuspend.cOnly in samsung/kernel/power: userwakelock.cOnly in samsung/kernel/power: wakelock.cOnly in samsung/mm: ashmem.cOnly in samsung/net: activity_stats.cOnly in samsung/net/ipv4: sysfs_net_ipv4.cOnly in samsung/sound/soc/codecs: wm8994_def.hOnly in samsung/sound/soc/codecs: wm8994_herring.cOnly in samsung/sound/soc/codecs: wm8994_samsung.cOnly in samsung/sound/soc/codecs: wm8994_samsung.hOnly in samsung/sound/soc/s3c24xx: herring-wm8994.cOnly in samsung/sound/soc/s3c24xx: s3c-dma-wrapper.cOnly in samsung/sound/soc/s3c24xx: s3c-idma.cOnly in samsung/sound/soc/s3c24xx: s3c-idma.hOnly in samsung/sound/soc/s3c24xx: s5p-i2s_sec.cOnly in samsung/sound/soc/s3c24xx: s5pc1xx-i2s.cOnly in samsung/sound/soc/s3c24xx: s5pc1xx-i2s.h

77

11.5 Sample process list using ps

$ psUSER PID PPID VSIZE RSS WCHAN PC NAMEroot 1 0 320 184 ffffffff 00000000 S /initroot 2 0 0 0 ffffffff 00000000 S kthreaddroot 3 2 0 0 ffffffff 00000000 S ksoftirqd/0root 4 2 0 0 ffffffff 00000000 S watchdog/0root 5 2 0 0 ffffffff 00000000 S events/0root 6 2 0 0 ffffffff 00000000 S khelperroot 7 2 0 0 ffffffff 00000000 S async/mgrroot 8 2 0 0 ffffffff 00000000 S suspendroot 9 2 0 0 ffffffff 00000000 S sync_supersroot 10 2 0 0 ffffffff 00000000 S bdi-defaultroot 11 2 0 0 ffffffff 00000000 S kblockd/0root 12 2 0 0 ffffffff 00000000 S kseriodroot 13 2 0 0 ffffffff 00000000 S kmmcdroot 14 2 0 0 ffffffff 00000000 S kondemand/0root 15 2 0 0 ffffffff 00000000 S pet_watchdog/0root 16 2 0 0 ffffffff 00000000 S khungtaskdroot 17 2 0 0 ffffffff 00000000 S kswapd0root 18 2 0 0 ffffffff 00000000 S crypto/0root 29 2 0 0 ffffffff 00000000 S kapmdroot 30 2 0 0 ffffffff 00000000 S pvr_timer/0root 31 2 0 0 ffffffff 00000000 S vsync_workqueueroot 32 2 0 0 ffffffff 00000000 S sec_jack_wqroot 33 2 0 0 ffffffff 00000000 S irq/38-sec_headroot 34 2 0 0 ffffffff 00000000 S irq/167-fsa9480root 35 2 0 0 ffffffff 00000000 S mtdblock0root 36 2 0 0 ffffffff 00000000 S mtdblock1root 37 2 0 0 ffffffff 00000000 S mtdblock2root 38 2 0 0 ffffffff 00000000 S mtdblock3root 39 2 0 0 ffffffff 00000000 S mtdblock4root 40 2 0 0 ffffffff 00000000 S mtdblock5root 41 2 0 0 ffffffff 00000000 S mtdblock6root 42 2 0 0 ffffffff 00000000 S spi_gpio.3root 49 2 0 0 ffffffff 00000000 S file-storageroot 50 2 0 0 ffffffff 00000000 S irq/308-mxt224_root 51 2 0 0 ffffffff 00000000 S irq/173-k3groot 52 2 0 0 ffffffff 00000000 S gp2a_wqroot 54 2 0 0 ffffffff 00000000 S kstripedroot 55 2 0 0 ffffffff 00000000 S kconservative/0root 56 2 0 0 ffffffff 00000000 S binderroot 57 2 0 0 ffffffff 00000000 S l2caproot 58 2 0 0 ffffffff 00000000 S krfcommdroot 59 2 0 0 ffffffff 00000000 S irq/334-cypressroot 60 2 0 0 ffffffff 00000000 S max8998-chargerroot 61 2 0 0 ffffffff 00000000 S irq/39-max8998-root 62 1 292 148 ffffffff 00000000 S /sbin/ueventdroot 63 2 0 0 ffffffff 00000000 S yaffs-bg-1root 64 2 0 0 ffffffff 00000000 S mmcqdroot 65 2 0 0 ffffffff 00000000 S yaffs-bg-1root 66 2 0 0 ffffffff 00000000 S jbd2/mmcblk0p1-root 67 2 0 0 ffffffff 00000000 S ext4-dio-unwritroot 68 2 0 0 ffffffff 00000000 S jbd2/mmcblk0p2-root 69 2 0 0 ffffffff 00000000 S ext4-dio-unwritsystem 70 1 816 120 ffffffff 00000000 S /system/bin/servicemanagerroot 71 1 3872 352 ffffffff 00000000 S /system/bin/voldroot 72 1 3856 252 ffffffff 00000000 S /system/bin/netdroot 73 1 676 128 ffffffff 00000000 S /system/bin/debuggerdradio 74 1 9260 1300 ffffffff 00000000 S /system/bin/rildroot 75 1 84796 19680 ffffffff 00000000 S zygotemedia 76 1 25036 2112 ffffffff 00000000 S /system/bin/mediaserverbluetooth 77 1 1264 136 ffffffff 00000000 S /system/bin/dbus-daemonroot 78 1 848 252 ffffffff 00000000 S /system/bin/installdkeystore 80 1 1752 100 ffffffff 00000000 S /system/bin/keystoregps 81 1 14380 3108 ffffffff 00000000 S /system/vendor/bin/gpsdshell 84 1 4464 208 ffffffff 00000000 S /sbin/adbdroot 89 2 0 0 ffffffff 00000000 S pvr_workqueuesystem 110 75 207728 69064 ffffffff 00000000 S system_serversystem 173 75 106008 28668 ffffffff 00000000 S com.android.systemuiroot 183 2 0 0 ffffffff 00000000 S iscan_sysioc

78

root 184 2 0 0 ffffffff 00000000 S dhcp_sysiocroot 185 2 0 0 ffffffff 00000000 S dhd_watchdogroot 186 2 0 0 ffffffff 00000000 S dhd_dpcroot 187 2 0 0 ffffffff 00000000 S dhd_sysiocapp_34 188 75 103132 23732 ffffffff 00000000 S com.google.android.inputmethod.latinradio 192 75 110900 19488 ffffffff 00000000 S com.android.phonenfc 193 75 98940 15308 ffffffff 00000000 S com.android.nfc3app_32 196 75 139612 57312 ffffffff 00000000 S com.android.launcherapp_21 229 75 151300 33340 ffffffff 00000000 S com.google.process.gappswifi 247 1 2176 596 ffffffff 00000000 S /system/bin/wpa_supplicantapp_26 346 75 100420 19000 ffffffff 00000000 S android.process.mediaapp_49 452 75 95880 15956 ffffffff 00000000 S com.android.providers.calendarroot 5258 2 0 0 ffffffff 00000000 S loop0root 5259 2 0 0 ffffffff 00000000 S kdmflushroot 5260 2 0 0 ffffffff 00000000 S kcryptd_ioroot 5261 2 0 0 ffffffff 00000000 S kcryptdapp_82 5404 75 124352 32100 ffffffff 00000000 S com.gowallaapp_28 5416 75 122504 22256 ffffffff 00000000 S com.google.android.apps.mapsapp_1 10655 75 93924 15880 ffffffff 00000000 S com.noshufou.android.suapp_28 10684 75 99540 19328 ffffffff 00000000 S com.google.android.apps.maps:FriendServiceapp_36 10692 75 95896 17544 ffffffff 00000000 S com.google.android.googlequicksearchboxapp_55 10864 75 100768 22024 ffffffff 00000000 S com.doubleTwist.androidPlayerapp_9 10873 75 96988 20340 ffffffff 00000000 S android.process.acoreapp_59 10951 75 93444 16636 ffffffff 00000000 S com.disqus.Disqusapp_25 11080 75 96556 16184 ffffffff 00000000 S com.google.android.apps.uploaderapp_40 11089 75 96216 17948 ffffffff 00000000 S com.google.android.gmapp_74 11097 75 120692 29268 ffffffff 00000000 S com.google.android.apps.plusapp_69 11109 75 97392 19724 ffffffff 00000000 S com.facebook.katanadhcp 11129 1 860 372 ffffffff 00000000 S /system/bin/dhcpcdapp_22 11172 75 106524 21628 ffffffff 00000000 S com.google.android.musicapp_28 11193 75 107976 21668 ffffffff 00000000 S com.google.android.apps.maps:NetworkLocationServiceroot 11215 2 0 0 ffffffff 00000000 S flush-179:0shell 11220 84 744 336 c005bfb4 afd0c3ac S /system/bin/shshell 11221 11220 900 308 00000000 afd0b45c R ps

79

11.6 init.rc Script

on early-init start ueventd

on init

sysclktz 0

loglevel 3

# setup the global environment export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin export LD_LIBRARY_PATH /vendor/lib:/system/lib export ANDROID_BOOTLOGO 1 export ANDROID_ROOT /system export ANDROID_ASSETS /system/app export ANDROID_DATA /data export EXTERNAL_STORAGE /mnt/sdcard export ASEC_MOUNTPOINT /mnt/asec export LOOP_MOUNTPOINT /mnt/obb export BOOTCLASSPATH /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar

# Backward compatibility symlink /system/etc /etc symlink /sys/kernel/debug /d

# Right now vendor lives on the same filesystem as system,# but someday that may change. symlink /system/vendor /vendor

# create mountpoints mkdir /mnt 0775 root system mkdir /mnt/sdcard 0000 system system

# Create cgroup mount point for cpu accounting mkdir /acct mount cgroup none /acct cpuacct mkdir /acct/uid

# Backwards Compat - XXX: Going away in G* symlink /mnt/sdcard /sdcard

mkdir /system mkdir /data 0771 system system mkdir /cache 0770 system cache mkdir /config 0500 root root

# Directory for putting things only root should see. mkdir /mnt/secure 0700 root root

# Directory for staging bindmounts mkdir /mnt/secure/staging 0700 root root

# Directory-target for where the secure container # imagefile directory will be bind-mounted mkdir /mnt/secure/asec 0700 root root

# Secure container public mount points. mkdir /mnt/asec 0700 root system mount tmpfs tmpfs /mnt/asec mode=0755,gid=1000

# Filesystem image public mount points. mkdir /mnt/obb 0700 root system mount tmpfs tmpfs /mnt/obb mode=0755,gid=1000

write /proc/sys/kernel/panic_on_oops 1 write /proc/sys/kernel/hung_task_timeout_secs 0 write /proc/cpu/alignment 4

80

write /proc/sys/kernel/sched_latency_ns 10000000 write /proc/sys/kernel/sched_wakeup_granularity_ns 2000000 write /proc/sys/kernel/sched_compat_yield 1 write /proc/sys/kernel/sched_child_runs_first 0

# Create cgroup mount points for process groups mkdir /dev/cpuctl mount cgroup none /dev/cpuctl cpu chown system system /dev/cpuctl chown system system /dev/cpuctl/tasks chmod 0777 /dev/cpuctl/tasks write /dev/cpuctl/cpu.shares 1024

mkdir /dev/cpuctl/fg_boost chown system system /dev/cpuctl/fg_boost/tasks chmod 0777 /dev/cpuctl/fg_boost/tasks write /dev/cpuctl/fg_boost/cpu.shares 1024

mkdir /dev/cpuctl/bg_non_interactive chown system system /dev/cpuctl/bg_non_interactive/tasks chmod 0777 /dev/cpuctl/bg_non_interactive/tasks # 5.0 % write /dev/cpuctl/bg_non_interactive/cpu.shares 52

on fs# mount mtd partitions # Mount /system rw first to give the filesystem a chance to save a checkpoint mount yaffs2 mtd@system /system mount yaffs2 mtd@system /system ro remount mount yaffs2 mtd@userdata /data nosuid nodev mount yaffs2 mtd@cache /cache nosuid nodev

on post-fs # once everything is setup, no need to modify / mount rootfs rootfs / ro remount

# We chown/chmod /data again so because mount is run as root + defaults chown system system /data chmod 0771 /data

# Create dump dir and collect dumps. # Do this before we mount cache so eventually we can use cache for # storing dumps on platforms which do not have a dedicated dump partition. mkdir /data/dontpanic chown root log /data/dontpanic chmod 0750 /data/dontpanic

# Collect apanic data, free resources and re-arm trigger copy /proc/apanic_console /data/dontpanic/apanic_console chown root log /data/dontpanic/apanic_console chmod 0640 /data/dontpanic/apanic_console

copy /proc/apanic_threads /data/dontpanic/apanic_threads chown root log /data/dontpanic/apanic_threads chmod 0640 /data/dontpanic/apanic_threads

write /proc/apanic_console 1

# Same reason as /data above chown system cache /cache chmod 0770 /cache

# This may have been created by the recovery system with odd permissions chown system cache /cache/recovery chmod 0770 /cache/recovery

#change permissions on vmallocinfo so we can grab it from bugreports chown root log /proc/vmallocinfo chmod 0440 /proc/vmallocinfo

#change permissions on kmsg & sysrq-trigger so bugreports can grab kthread stacks chown root system /proc/kmsg chmod 0440 /proc/kmsg

81

chown root system /proc/sysrq-trigger chmod 0220 /proc/sysrq-trigger

# create basic filesystem structure mkdir /data/misc 01771 system misc mkdir /data/misc/bluetoothd 0770 bluetooth bluetooth mkdir /data/misc/bluetooth 0770 system system mkdir /data/misc/keystore 0700 keystore keystore mkdir /data/misc/vpn 0770 system system mkdir /data/misc/systemkeys 0700 system system mkdir /data/misc/vpn/profiles 0770 system system # give system access to wpa_supplicant.conf for backup and restore mkdir /data/misc/wifi 0770 wifi wifi chmod 0770 /data/misc/wifi chmod 0660 /data/misc/wifi/wpa_supplicant.conf mkdir /data/local 0771 shell shell mkdir /data/local/tmp 0771 shell shell mkdir /data/data 0771 system system mkdir /data/app-private 0771 system system mkdir /data/app 0771 system system mkdir /data/property 0700 root root

# create dalvik-cache and double-check the perms mkdir /data/dalvik-cache 0771 system system chown system system /data/dalvik-cache chmod 0771 /data/dalvik-cache

# create the lost+found directories, so as to enforce our permissions mkdir /data/lost+found 0770 mkdir /cache/lost+found 0770

# double check the perms, in case lost+found already exists, and set owner chown root root /data/lost+found chmod 0770 /data/lost+found chown root root /cache/lost+found chmod 0770 /cache/lost+found

on boot# basic network init ifup lo hostname localhost domainname localdomain

# set RLIMIT_NICE to allow priorities from 19 to -20 setrlimit 13 40 40

# Define the oom_adj values for the classes of processes that can be# killed by the kernel. These are used in ActivityManagerService. setprop ro.FOREGROUND_APP_ADJ 0 setprop ro.VISIBLE_APP_ADJ 1 setprop ro.PERCEPTIBLE_APP_ADJ 2 setprop ro.HEAVY_WEIGHT_APP_ADJ 3 setprop ro.SECONDARY_SERVER_ADJ 4 setprop ro.BACKUP_APP_ADJ 5 setprop ro.HOME_APP_ADJ 6 setprop ro.HIDDEN_APP_MIN_ADJ 7 setprop ro.EMPTY_APP_ADJ 15

# Define the memory thresholds at which the above process classes will# be killed. These numbers are in pages (4k). setprop ro.FOREGROUND_APP_MEM 2048 setprop ro.VISIBLE_APP_MEM 3072 setprop ro.PERCEPTIBLE_APP_MEM 4096 setprop ro.HEAVY_WEIGHT_APP_MEM 4096 setprop ro.SECONDARY_SERVER_MEM 6144 setprop ro.BACKUP_APP_MEM 6144 setprop ro.HOME_APP_MEM 6144 setprop ro.HIDDEN_APP_MEM 7168 setprop ro.EMPTY_APP_MEM 8192

# Write value must be consistent with the above properties.# Note that the driver only supports 6 slots, so we have combined some of# the classes into the same memory level; the associated processes of higher# classes will still be killed first.

82

write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15

write /proc/sys/vm/overcommit_memory 1 write /proc/sys/vm/min_free_order_shift 4 write /sys/module/lowmemorykiller/parameters/minfree 2048,3072,4096,6144,7168,8192

# Set init its forked children's oom_adj. write /proc/1/oom_adj -16

# Tweak background writeout write /proc/sys/vm/dirty_expire_centisecs 200 write /proc/sys/vm/dirty_background_ratio 5

# Permissions for System Server and daemons. chown radio system /sys/android_power/state chown radio system /sys/android_power/request_state chown radio system /sys/android_power/acquire_full_wake_lock chown radio system /sys/android_power/acquire_partial_wake_lock chown radio system /sys/android_power/release_wake_lock chown radio system /sys/power/state chown radio system /sys/power/wake_lock chown radio system /sys/power/wake_unlock chmod 0660 /sys/power/state chmod 0660 /sys/power/wake_lock chmod 0660 /sys/power/wake_unlock chown system system /sys/class/timed_output/vibrator/enable chown system system /sys/class/leds/keyboard-backlight/brightness chown system system /sys/class/leds/lcd-backlight/brightness chown system system /sys/class/leds/button-backlight/brightness chown system system /sys/class/leds/jogball-backlight/brightness chown system system /sys/class/leds/red/brightness chown system system /sys/class/leds/green/brightness chown system system /sys/class/leds/blue/brightness chown system system /sys/class/leds/red/device/grpfreq chown system system /sys/class/leds/red/device/grppwm chown system system /sys/class/leds/red/device/blink chown system system /sys/class/leds/red/brightness chown system system /sys/class/leds/green/brightness chown system system /sys/class/leds/blue/brightness chown system system /sys/class/leds/red/device/grpfreq chown system system /sys/class/leds/red/device/grppwm chown system system /sys/class/leds/red/device/blink chown system system /sys/class/timed_output/vibrator/enable chown system system /sys/module/sco/parameters/disable_esco chown system system /sys/kernel/ipv4/tcp_wmem_min chown system system /sys/kernel/ipv4/tcp_wmem_def chown system system /sys/kernel/ipv4/tcp_wmem_max chown system system /sys/kernel/ipv4/tcp_rmem_min chown system system /sys/kernel/ipv4/tcp_rmem_def chown system system /sys/kernel/ipv4/tcp_rmem_max chown root radio /proc/cmdline

# Define TCP buffer sizes for various networks# ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax, setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.wifi 4095,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.umts 4094,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.edge 4093,26280,35040,4096,16384,35040 setprop net.tcp.buffersize.gprs 4092,8760,11680,4096,8760,11680

class_start default

## Daemon processes to be run by init.##service ueventd /sbin/ueventd critical

service console /system/bin/sh console disabled user shell group log

83

on property:ro.secure=0! start console

# adbd is controlled by the persist.service.adb.enable system propertyservice adbd /sbin/adbd disabled

# adbd on at boot in emulatoron property:ro.kernel.qemu=1 start adbd

on property:persist.service.adb.enable=1 start adbd

on property:persist.service.adb.enable=0 stop adbd

service servicemanager /system/bin/servicemanager user system critical onrestart restart zygote onrestart restart media

service vold /system/bin/vold socket vold stream 0660 root mount ioprio be 2

service netd /system/bin/netd socket netd stream 0660 root system

service debuggerd /system/bin/debuggerd

service ril-daemon /system/bin/rild socket rild stream 660 root radio socket rild-debug stream 660 radio system user root group radio cache inet misc audio sdcard_rw

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server socket zygote stream 666 onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd

service media /system/bin/mediaserver user media group system audio camera graphics inet net_bt net_bt_admin net_raw ioprio rt 4

service bootanim /system/bin/bootanimation user graphics group graphics disabled oneshot

service dbus /system/bin/dbus-daemon --system --nofork socket dbus stream 660 bluetooth bluetooth user bluetooth group bluetooth net_bt_admin

service bluetoothd /system/bin/bluetoothd -n socket bluetooth stream 660 bluetooth bluetooth socket dbus_bluetooth stream 660 bluetooth bluetooth # init.rc does not yet support applying capabilities, so run as root and # let bluetoothd drop uid to bluetooth with the right linux capabilities group bluetooth net_bt_admin misc disabled

service hfag /system/bin/sdptool add --channel=10 HFAG user bluetooth group bluetooth net_bt_admin disabled

84

oneshot

service hsag /system/bin/sdptool add --channel=11 HSAG user bluetooth group bluetooth net_bt_admin disabled oneshot

service opush /system/bin/sdptool add --channel=12 OPUSH user bluetooth group bluetooth net_bt_admin disabled oneshot

service pbap /system/bin/sdptool add --channel=19 PBAP user bluetooth group bluetooth net_bt_admin disabled oneshot

service installd /system/bin/installd socket installd stream 600 system system

service flash_recovery /system/etc/install-recovery.sh oneshot

service racoon /system/bin/racoon socket racoon stream 600 system system # racoon will setuid to vpn after getting necessary resources. group net_admin disabled oneshot

service mtpd /system/bin/mtpd socket mtpd stream 600 system system user vpn group vpn net_admin net_raw disabled oneshot

service keystore /system/bin/keystore /data/misc/keystore user keystore group keystore socket keystore stream 666

service dumpstate /system/bin/dumpstate -s socket dumpstate stream 0660 shell log disabled oneshot

85

11.7 Sample MANIFEST.MF

Manifest-Version: 1.0Created-By: 1.0 (Android)

Name: res/layout/main.xmlSHA1-Digest: J291fl4ABGvK1CsYgJEpeDSWEo8=

Name: res/drawable-ldpi/icon.pngSHA1-Digest: i7vxaosoiS+9HzKB7ZgIsXMYRLY=

Name: AndroidManifest.xmlSHA1-Digest: ePodAtUbXFQfUlRNPTvbdnQrXDw=

Name: res/drawable-mdpi/icon.pngSHA1-Digest: 7Ft/Rirt+l/JRX2KjDREScdbCZk=

Name: resources.arscSHA1-Digest: HrkO4tPxiaPdoeNDcDx9bkZfw0s=

Name: classes.dexSHA1-Digest: DMvzC9dwuhlQ6AM7/A/j7d8Ls4Y=

Name: res/drawable-hdpi/icon.pngSHA1-Digest: Vj/qhxk8ic8FE0/kT6E3vgRJ4mE=

86

11.8 Sample CERT.SF

Signature-Version: 1.0Created-By: 1.0 (Android)SHA1-Digest-Manifest: Z4dOkdGC2xQJTdF+PLiUTw8d8qU=

Name: res/layout/main.xmlSHA1-Digest: CCybDEnTwOIdsk2rYh/ebMQ2dZ4=

Name: AndroidManifest.xmlSHA1-Digest: hGh9ygILugOxn+ObWZxRZdhZ29g=

Name: res/drawable-ldpi/icon.pngSHA1-Digest: Z/yxmMxGRNbFUkjqWONvJQH5rQw=

Name: res/drawable-mdpi/icon.pngSHA1-Digest: iR1AGdcgDutAX/5xyl92TWcEJuw=

Name: resources.arscSHA1-Digest: Uh5cbP8vR2hxtdEJm+kXH5gdv0M=

Name: classes.dexSHA1-Digest: cTs5Sx+iEZM8UOoh66Jew7J7kbI=

Name: res/drawable-hdpi/icon.pngSHA1-Digest: 3vv9derC/UrLpiam9i2Yo16eHXw=

87

11.9 Android Application to Test Permissions and Runtime.Exec

package org.thirdly.test;

import android.app.Activity;import android.os.Bundle;import android.os.Environment;import java.io.*;

public class TesterActivity extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); File newFile = getDir("whee", MODE_PRIVATE);!! System.out.println("Can write to " + newFile.getAbsolutePath() + "? " + newFile.canWrite()); try { !File text = new File(newFile, "whee"); !text.setExecutable(true); !FileWriter writer = new FileWriter(text); !writer.append("echo hello world"); !writer.flush(); !writer.close(); } catch (IOException e) { !e.printStackTrace(); } Runtime rt = Runtime.getRuntime(); try {!!!Process proc = rt.exec("ls -l " + newFile.getAbsolutePath() + "/whee");!!!InputStream stdin = proc.getInputStream(); InputStreamReader isr = new InputStreamReader(stdin); BufferedReader br = new BufferedReader(isr); String line = null; System.out.println("<OUTPUT>"); while ( (line = br.readLine()) != null) System.out.println(line); System.out.println("</OUTPUT>");!!} catch (IOException e) {!!!// TODO Auto-generated catch block!!!e.printStackTrace();!!} }}

88

11.10 Sample netstat -a output

# netstat -aProto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:7777 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:7203 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:7777 127.0.0.1:56000 ESTABLISHED tcp 0 0 127.0.0.1:7777 127.0.0.1:55999 ESTABLISHED tcp 0 0 127.0.0.1:56000 127.0.0.1:7777 ESTABLISHED tcp 0 0 127.0.0.1:55999 127.0.0.1:7777 ESTABLISHEDtcp6 0 1 ::ffff:10.0.1.16:37799 ::ffff:74.125.71.147:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:44067 ::ffff:74.125.71.104:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:60937 ::ffff:74.125.71.101:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:34032 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:50296 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:38326 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 0 ::ffff:10.0.1.16:51468 ::ffff:107.20.160.88:443 ESTABLISHEDtcp6 0 0 ::ffff:10.0.1.16:57346 ::ffff:74.125.71.188:5228 ESTABLISHEDtcp6 0 1 ::ffff:10.0.1.16:38043 ::ffff:74.125.71.101:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:44053 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:41730 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:50187 ::ffff:74.125.71.100:443 CLOSE_WAIT

89