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 Abbreviations 3. Introduction
3.1 Platform versus Operating System 3.2 Objectives 3.3 Research Details 3.3 Tools used

1 1 2
3 3 4 5

4. The Android Platform

4.1 Philosophy 4.2 Hardware 4.3 Kernel 4.4 Operating System 4.5 Third Party Development

6
6 7 8 9 21

5. Security Audit
5.1 Existing Protection 5.2 Attack Surface 5.3 Chain of Trust violation through Full Access 5.4 Existing Security Compromises 5.5 Conclusion

24
25 31 35 39 42

6. Securing Android
6.1 Philosophy 6.2 Existing Work 6.3 Mandatory Access Control

43
43 47 49

6.4 Hardening

51

7. Proof of Concept
7.1 Security Enhanced Linux 7.2 Patching Dalvik 7.3 grsecurity Patches 7.4 Test and Audit Tool

56
57 58 56 58

8. Conclusion Recommendations References 11. Appendix

11.1 Android /system/bin 11.2 Ubuntu /bin 11.3 Android Filesystem Configuration Header 11.4 New files added to Android Kernel 11.5 Sample process list using ps 11.6 init.rc Script 11.7 Sample MANIFEST.MF 11.8 Sample CERT.SF 11.9 Android Application to Test Permissions and Runtime.Exec 11.10 Sample netstat -a output

59 61 62 67
67 69 71 75 78 80 86 87 88 89

Open source security issues of the Android Platform

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

2. Abbreviations
AOSP ARM SoC IPC NDK SDK LSB POSIX GNU BSD GPL LGPL EXT4 YAFFS ROP OLPC UID GID DAC MAC ABI ADB JNI XSS DEP ASLR PIC/PIE NX Android Open Source Project Advanced RISC Machines System on a Chip Inter Process Communication Native Development Kit Software Development Kit Linux Standard Base Portable Operating System Interface for Unix GNU is Not Unix Berkeley Software Distribution GNU General Public License GNU Lesser General Public License Fourth Extended File System Yet Another Flash File System Return Oriented Programming One Laptop Per Child Linux User ID Linux Group ID Discretionary Access Control Mandatory Access Control Application Binary Interface Android Debug Bridge Java Native Interface Cross Site Scripting Data Execution Prevention Address Space Layout Randomization Position Independent Code/Execution No eXecute

Open source security issues of the Android Platform

3. Introduction
In the words of Google, Android was created as an alternative to Apples 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 Apples methods, opting for an open approach to almost every aspect of their platform versus what developers famously term, Apples 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.

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-VPGundotra-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 Apples iOS platform.

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 Androids 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 worlds largest internet company. As such, information from any reliable source is valuable,

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 Googles 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.

Open source security issues of the Android Platform

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.

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 doesnt guarantee a nexus droid [Web log message]. Retrieved from http://techcrunch.com/2011/08/15/googlemotorola-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 libc 5. 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

Patel, N. (2011, May 12). How google controls android: digging deep into the skyhook lings [Web log message]. Retrieved from http://thisismynext.com/2011/05/12/googleandroid-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/anintroduction-to-google-android-for-developers.ars

about 6. 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 Googles concentration on mobile devices, it is highly optimized and will officially only run on devices that have an ARM based processor 7. 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 Googles 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 wakelocks 8 power management

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-toboot-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 kernel 10. 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

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 les 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 Foundations 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

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-onandroid-the-linux-fork/9426
13

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

10

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.
$ mount rootfs / rootfs ro,relatime 0 0 tmpfs /dev tmpfs rw,relatime,mode=755 0 0 devpts /dev/pts devpts rw,relatime,mode=600 0 0 proc /proc proc rw,relatime 0 0 sysfs /sys sysfs rw,relatime 0 0 none /acct cgroup rw,relatime,cpuacct 0 0 tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0 tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0 none /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,ut f8,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,ut f8,errors=remount-ro 0 0 tmpfs /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=cp 437,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 image 14 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

14

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

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

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

12

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 BusyBox 19 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 kernel 20, Google chose to rewrite the C standard library.

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/androidkernel@googlegroups.com/msg03101.html
18 19 20

See Appendix Android /system/bin vs Ubuntu /bin Common UNIX utilities in a single executable. See 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/WhitepaperOpen-Source-Best-Practice/

13

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. Its 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.

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

14

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 support 23, 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 Javas Socket and Native IO or New IO

23

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

15

which has been around since Suns 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 Androids 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.
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-androidsystem-server

16

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 chown chown: 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 dalvikvm dalvikvm: 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 Androids 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
27

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

18

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 Androids 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

28

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

20

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 code 29 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.
29

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

21

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 execute 31.

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
30 31

http://www.clojure.org

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

22

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

Open source security issues of the Android Platform

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.

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-EaseAndroid-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

24

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

35

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

25

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 application 36, chief of which is the ability to share code and data if applications are signed using the same certificate. Additionally, applications can only be upgraded if the upgrade has been signed with a certificate that matches the existing applications 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.

36

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

26

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
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 40

See Appendix Sample CERT.SF See Appendix Sample MANIFEST.MF

27

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 runtimes 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

41

See Appendix for Android Filesystem Conguration Header

28

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.

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

29

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.

43

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

30

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.

44

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

31

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 Googles 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 Googles 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 Oberheides 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

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-attackandroid-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-thegtalkservice-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-ongoogle-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/

32

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 fuzzing 49 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 output 50 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

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

33

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 application 51 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.

51

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

34

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 doesnt allow non signed firmware updates. But the general idea is to prevent customers from flashing customized firmware onto their devices. On Googles 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

Starts Low Level Bootloader OS Bootloader

Loads Kernel

Runs init

Starts

Android Application

Starts zygote

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.

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 Facebook 53. The most notorious of which is Motorola which has additional protections54 to ensure that their bootloader is not compromised. This required much work 55 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.
52 53

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
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-saysefuse/
55

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

38

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.

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-requestingroot-access-in-your-app/

39

Paolo Passeri, an ex Security Consultant published his list for 2011s 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 doesnt seem to carry much wait in the press. Mcafees 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 DroidDream 59 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
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-androidmalware-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 ofcial android market [Web log message]. Retrieved from http://blog.mylookout.com/2011/03/ security-alert-malware-found-in-ofcial-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/

40

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 Skypes sqlite databases.
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-exposesphone-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-isexposing-your-name-phone-number-chat-logs-and-a-lot-more/

41

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

Open source security issues of the Android Platform

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%

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 awed assumption of security in modern computing environments. Paper presented at 21st national information systems security conference. Retrieved from http://www.nsa.gov/research/_les/selinux/papers/inevitabs.shtml
65

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

43

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 project 69 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 projects source code is

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 rst computer [Web log message]. Retrieved from http://technologizer.com/2011/03/28/my-mom-reviews-the-ipadher-rst-computer/
68 69

http://radian.org/

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/

44

open source and does not employ security by obscurity. Additionally, security is unobtrusive and does not get in the users way. While placing processes in their individual VMs are the gold standard 72 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

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/

45

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.

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

48

Biztrust 75 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.

75

UNGERLEIDER, N. (2011, October 10). The most secure android phone, ever [Web log message]. Retrieved from http://www.fastcompany.com/1786472/most-secure-androidphone-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_mobil esecuritywp

49

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, NSAs SELinux 77 stood out the most 78 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 Apples Mac OS X operating system and more successfully implemented on their iOS devices. Having SELinux support easily enabled within Androids Linux kernel through compile options made it the best choice for a MAC system for Android.

77 78

http://selinuxproject.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
79

http://www.trustedbsd.org

50

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 Androids 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 grsecurity 80 patches for the Linux kernel, so it is a fairly obvious choice to include it for Android as well.

80

http://www.grsecurity.net

51

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 PaX 81 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 doesnt 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

81 82

http://pax.grsecurity.net/ More explained in ASLR and DEP

52

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. Apples 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 readwrite-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 project 83 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 programmings84 return-to-libc

83 84

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

53

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. grsecuritys 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
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

54

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.

86

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

See 5.2.4 Code Execution

55

Open source security issues of the Android Platform

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 Androids 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 Androids kernel was found on a mirror 88 that held test versions of grsecurity. Test

88

http://mirrors.muarf.org/grsecurity/test/

56

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 doesnt let the kernel boot. More time and more understanding into kernel development is need to find fruition in this area.

7.2 Security Enhanced Linux

With 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 VMs 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 application 89 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 Apples 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.

89

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

58

Open source security issues of the Android Platform

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. Googles policy and philosophy towards their rapid platform growth with a small team in order to catch up with Apples 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

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

Open source security issues of the Android Platform

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.

61

Open source security issues of the Android Platform

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-VsApple-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 doesnt guarantee a nexus droid [Web log message]. Retrieved from http://techcrunch.com/2011/08/15/googlemotorola-deal-doesnt-guarantee-a-nexusdroid/

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-kernelproblems.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/linustorvalds-on-android-the-linux-fork/9426

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

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

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

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

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

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/498from-zero-to-boot-porting-android-to-yourarm-platform/

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

Smalley, S. (2011, May 11). Re: [androidkernel] froyo : ext4 instead of yaffs2 [Electronic mailing list message]. Retrieved

62

from http://www.mail-archive.com/androidkernel@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-ForDevices-Articles/Whitepaper-Open-SourceBest-Practice/

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

http://www.clojure.org

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

Gmez, 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-withclojure

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

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

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

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

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/androidbluetooth-introduction

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

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

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

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

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

jon.oberheide.org/blog/2011/03/07/how-ialmost-won-pwn2own-via-xss/

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

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

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

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

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

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/motorolaresponds-to-droid-x-bootloadercontroversy-says-efuse/

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

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

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-peekinside-the-gtalkservice-connection/

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/

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/remotekill-and-install-on-google-android/

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/

Oberheide, J. (2011, March 07). How i almost won pwn2own via xss [Web log message]. Retrieved from http://

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

64

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

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

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

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

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

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

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-htcandroid-devices-evo-3d-4g-thunderboltothers-exposes-phone-numbers-gps-smsemails-addresses-much-more/

http://radian.org/

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

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-androidis-exposing-your-name-phone-numberchat-logs-and-a-lot-more/

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-xlion-072111

http://linux-vserver.org/

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

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 awed assumption of security in modern computing environments. Paper presented at 21st national information systems security conference. Retrieved from http:// www.nsa.gov/research/_les/selinux/ papers/inevit-abs.shtml

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/mostsecure-android-phone-ever-blackberryheadache?partner=gnews

http://mirrors.muarf.org/ grsecurity/test/

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.pd f? 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-executablestack 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 ght continues [Web log message]. Retrieved from http:// blogs.computerworld.com/16900/ android_linux_kernel_ght_continues

66

Open source security issues of the Android Platform

11. Appendix
11.1 Android /system/bin
# ls -l -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-s---rwxr-xr-x root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell inet shell 191 5720 49924 5292 199 23160 10116 5556 2010-11-25 2010-11-25 2011-05-04 2010-11-25 2010-11-25 2010-11-25 2010-11-25 2010-11-25 2010-11-30 2010-11-30 2010-11-30 2010-11-30 2011-05-04 2010-11-30 2011-05-04 2010-11-30 2011-05-04 2011-05-04 2010-11-30 2011-05-04 2010-11-30 2011-05-04 2010-11-25 2010-11-25 2010-11-25 2011-05-04 2010-11-30 2010-11-30 2011-05-04 2011-05-04 2010-11-30 2010-11-30 2010-11-30 2010-11-30 2010-11-25 2010-11-25 2010-11-30 2011-05-04 2010-11-30 2010-11-30 2011-05-04 2011-05-04 2010-11-30 2011-05-04 2010-11-30 2010-11-30 2011-05-04 2011-05-04 2010-11-30 2010-11-30 2010-11-30 2010-11-25 2010-11-25 2010-11-30 2010-11-25 2010-11-30 2011-05-04 2010-11-30 2010-11-30 2010-11-25 2011-05-04 2011-05-04 05:42 05:42 02:10 05:42 05:42 05:42 05:42 05:42 07:30 07:30 07:30 07:30 02:10 07:30 02:10 07:30 02:10 02:10 07:30 02:10 07:30 02:10 05:42 05:42 05:42 02:10 07:30 07:30 02:10 02:10 07:30 07:30 07:30 07:30 05:42 05:42 07:30 02:10 07:30 07:30 02:10 02:10 07:30 02:10 07:30 07:30 02:10 02:10 07:30 07:30 07:30 05:42 05:42 07:30 05:42 07:30 02:10 07:30 07:30 05:42 02:10 02:10 am app_process applypatch bluetoothd bmgr bootanimation brcm_patchram_plus bugreport cat -> toolbox chmod -> toolbox chown -> toolbox cmp -> toolbox dalvikvm date -> toolbox dbus-daemon dd -> toolbox debuggerd dexopt df -> toolbox dhcpcd dmesg -> toolbox dnsmasq dumpstate dumpsys dvz fsck_msdos getevent -> toolbox getprop -> toolbox gzip hciattach hd -> toolbox id -> toolbox ifconfig -> toolbox iftop -> toolbox ime input insmod -> toolbox installd ioctl -> toolbox ionice -> toolbox iptables keystore kill -> toolbox linker ln -> toolbox log -> toolbox logcat logwrapper ls -> toolbox lsmod -> toolbox lsof -> toolbox make_ext4fs mediaserver mkdir -> toolbox monkey mount -> toolbox mtpd mv -> toolbox nandread -> toolbox ndc netcfg netd

5520 109504 18112 9796 44596 108820 34544 9812 5548 22640 5604 23284

194 201 22420 100916 10112 39416 13952 9760

5504 5488 205 18308 5552 5660 31172

67

lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-sr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwsr-s---rwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x -rwxr-xr-x lrwxr-xr-x lrwxr-xr-x -rwxr-xr-x -rwsr-sr-x -rwxr-xr-x drwxrwxrwx

root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root

shell shell shell shell shell net_raw shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell shell root shell root

32600 18692 26720 191 139540 142516 9808

59848 5392 9748 42404 9860 9940 5564 82840

5456 192 5472 67956 81544

5552 51700 291876 22228 24120

2010-11-30 2010-11-30 2010-11-30 2011-05-04 2010-11-25 2011-05-04 2010-11-25 2011-05-04 2010-11-30 2010-11-30 2011-05-04 2010-11-30 2010-11-30 2011-05-04 2010-11-30 2010-11-30 2010-11-30 2010-11-30 2011-05-04 2010-11-25 2010-11-30 2010-11-25 2010-11-25 2010-11-30 2010-11-25 2011-05-04 2010-11-30 2010-11-30 2010-11-25 2011-05-04 2010-11-30 2010-11-30 2010-11-30 2010-11-30 2011-05-04 2010-11-25 2010-11-30 2010-11-25 2011-05-04 2011-05-04 2010-11-30 2010-11-30 2010-11-30 2010-11-25 2010-11-30 2011-05-04 2010-11-30 2010-11-30 2011-05-04 2011-09-29 2011-03-23 2011-09-29

07:30 07:30 07:30 02:10 05:42 02:10 05:42 02:10 07:30 07:30 02:10 07:30 07:30 02:10 07:30 07:30 07:30 07:30 02:10 05:42 07:30 05:42 05:42 07:30 05:42 02:10 07:30 07:30 05:42 02:10 07:30 07:30 07:30 07:30 02:10 05:42 07:30 05:42 02:10 02:10 07:30 07:30 07:30 05:42 07:30 02:10 07:30 07:30 02:10 21:16 19:51 21:40

netstat -> toolbox newfs_msdos -> toolbox notify -> toolbox omx_tests pand ping pm pppd printenv -> toolbox ps -> toolbox racoon reboot -> toolbox renice -> toolbox rild rm -> toolbox rmdir -> toolbox rmmod -> toolbox route -> toolbox run-as schedtest schedtop -> toolbox sdcard sdptool sendevent -> toolbox service servicemanager setconsole -> toolbox setprop -> toolbox setup_fs sh sleep -> toolbox smd -> toolbox start -> toolbox stop -> toolbox surfaceflinger svc sync -> toolbox system_server tc toolbox top -> toolbox umount -> toolbox uptime -> toolbox vdc vmstat -> toolbox vold watchprops -> toolbox wipe -> toolbox wpa_supplicant su sqlite3 failsafe

68

11.2 Ubuntu /bin

jeremy@jeremy-ubuntu:/bin$ ls -l total 8108 -rwxr-xr-x 1 root root 954896 2011-04-01 -rwxr-xr-x 1 root root 31112 2011-02-21 -rwxr-xr-x 1 root root 1964728 2011-02-23 -rwxr-xr-x 1 root root 31112 2011-02-21 lrwxrwxrwx 1 root root 6 2011-07-31 -rwxr-xr-x 1 root root 2140 2011-02-21 lrwxrwxrwx 1 root root 6 2011-07-31 -rwxr-xr-x 1 root root 4874 2011-02-21 lrwxrwxrwx 1 root root 6 2011-07-31 -rwxr-xr-x 1 root root 3642 2011-02-21 -rwxr-xr-x 1 root root 31112 2011-02-21 -rwxr-xr-x 1 root root 10336 2011-02-21 lrwxrwxrwx 1 root root 6 2011-07-31 -rwxr-xr-x 1 root root 1297 2011-02-21 -rwxr-xr-x 1 root root 47696 2011-02-23 -rwxr-xr-x 1 root root 55864 2011-02-23 -rwxr-xr-x 1 root root 51704 2011-02-23 -rwxr-xr-x 1 root root 55880 2011-02-23 -rwxr-xr-x 1 root root 10392 2011-03-18 -rwxr-xr-x 1 root root 117808 2011-02-23 -rwxr-xr-x 1 root root 137232 2011-02-24 -rwxr-xr-x 1 root root 109736 2010-11-15 -rwxr-xr-x 1 root root 55832 2011-02-23 -rwxr-xr-x 1 root root 10464 2011-07-23 -rwxr-xr-x 1 root root 351448 2011-07-23 -rwxr-xr-x 1 root root 10376 2011-07-23 -rwxr-xr-x 1 root root 51840 2011-02-23 -rwxr-xr-x 1 root root 64208 2011-02-23 -rwxr-xr-x 1 root root 105776 2011-02-23 -rwxr-xr-x 1 root root 10368 2011-03-21 -rwxr-xr-x 1 root root 14688 2010-11-17 -rwxr-xr-x 1 root root 14688 2010-11-17 -rwxr-xr-x 1 root root 82152 2011-03-18 -rwxr-xr-x 1 root root 26968 2011-02-23 -rwxr-xr-x 1 root root 47552 2010-10-30 -rwxr-xr-x 1 root root 126240 2010-11-18 -rwxr-xr-x 1 root root 22856 2011-02-23 -rwxr-xr-x 1 root root 10408 2011-03-18 -rwxr-xr-x 1 root root 85088 2010-11-18 -rwxr-xr-x 1 root root 31680 2010-10-16 -rwsr-xr-x 1 root root 31320 2011-02-11 -rwxr-xr-x 1 root root 126272 2010-11-18 -rwxr-xr-x 1 root root 63 2010-08-17 -rwxr-xr-x 1 root root 5874 2010-08-17 -rwxr-xr-x 1 root root 64168 2010-08-17 -rwxr-xr-x 1 root root 14688 2010-11-17 -rwxr-xr-x 1 root root 5564 2011-04-21 -rwxr-xr-x 1 root root 16005 2011-04-21 -rwxr-xr-x 1 root root 234768 2010-10-15 -rwxr-xr-x 1 root root 10400 2011-03-18 -rwxr-xr-x 1 root root 18736 2011-04-07 -rwxr-xr-x 1 root root 149496 2009-11-05 -rwxr-xr-x 1 root root 10504 2009-11-05 lrwxrwxrwx 1 root root 8 2011-07-31 -rwxr-xr-x 1 root root 15840 2009-11-05 -rwxr-xr-x 1 root root 6947 2009-11-05 -rwxr-xr-x 1 root root 47680 2011-02-23 -rwxr-xr-x 1 root root 111288 2011-03-18 -rwxr-xr-x 1 root root 44928 2011-02-21 -rwxr-xr-x 1 root root 57000 2010-09-16 -rwxr-xr-x 1 root root 105776 2011-02-23 -rwxr-xr-x 1 root root 6088 2011-04-01 -rwxr-xr-x 1 root root 47624 2011-02-23 -rwxr-xr-x 1 root root 31112 2011-02-23 -rwxr-xr-x 1 root root 35352 2011-02-23 -rwxr-xr-x 1 root root 35448 2011-03-21 -rwsr-xr-x 1 root root 82224 2011-03-21 -rwxr-xr-x 1 root root 10264 2011-03-29 05:20 00:13 11:30 00:13 02:47 00:13 02:47 00:13 02:47 00:13 00:13 00:13 02:47 00:13 22:24 22:24 22:24 22:24 07:47 22:24 01:49 16:34 22:24 01:05 01:05 01:05 22:24 22:24 22:24 16:28 23:51 23:51 07:47 22:24 00:45 12:09 22:24 07:47 12:09 00:47 05:03 12:09 16:43 16:43 16:43 23:51 06:56 06:56 20:45 07:47 23:36 16:52 16:52 02:47 16:52 16:51 22:24 07:47 08:18 08:23 22:24 22:05 22:24 22:24 22:24 16:28 16:28 04:21 bash bunzip2 busybox bzcat bzcmp -> bzdiff bzdiff bzegrep -> bzgrep bzexe bzfgrep -> bzgrep bzgrep bzip2 bzip2recover bzless -> bzmore bzmore cat chgrp chmod chown chvt cp cpio dash date dbus-cleanup-sockets dbus-daemon dbus-uuidgen dd df dir dmesg dnsdomainname domainname dumpkeys echo ed egrep false fgconsole fgrep fuser fusermount grep gunzip gzexe gzip hostname init-checkconf initctl2dot ip kbd_mode kill less lessecho lessfile -> lesspipe lesskey lesspipe ln loadkeys login lowntfs-3g ls lsmod mkdir mknod mktemp more mount mountpoint

69

lrwxrwxrwx -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxrwxrwx -rwxr-xr-x lrwxrwxrwx -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxrwxrwx -rwxr-xr-x lrwxrwxrwx -rwsr-xr-x -rwsr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxrwxrwx -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxrwxrwx -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x lrwxrwxrwx lrwxrwxrwx -rwxr-xr-x lrwxrwxrwx -rwxr-xr-x -rwsr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwsr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x -rwxr-xr-x

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root

root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root root

20 68712 109584 191960 20 31152 24 120184 14688 52800 10368 55816 14576 6 14688 14 35680 40248 35360 31560 101184 31200 4 35272 55872 39320 4 15048 69024 39744 12052 4 4 26984 7 63992 36832 22872 10488 311888 10312 47640 22856 14656 56616 27016 63 2762 105776 6200 946 14688 64 69 4424 64 64 2015 5597 1733 2416 4952

2011-07-31 2011-02-24 2011-02-23 2010-12-04 2011-07-31 2011-01-05 2011-07-31 2010-07-02 2010-11-17 2010-09-16 2010-09-16 2010-09-16 2010-09-16 2011-07-31 2011-03-18 2011-07-31 2010-11-15 2010-11-15 2011-04-27 2011-04-27 2011-04-07 2011-02-23 2011-07-31 2011-02-23 2011-02-23 2011-02-23 2011-07-31 2011-01-20 2010-11-16 2011-03-18 2011-04-21 2011-07-31 2011-07-31 2011-02-23 2011-07-31 2011-02-23 2011-02-21 2011-02-23 2011-03-21 2010-12-07 2011-01-20 2011-02-23 2011-02-23 2011-02-11 2011-03-21 2011-02-23 2010-08-17 2011-03-18 2011-02-23 2011-02-23 2011-01-20 2010-11-17 2010-08-17 2010-08-17 2010-08-17 2010-08-17 2010-08-17 2010-08-17 2010-08-17 2010-08-17 2010-08-17 2010-08-17

02:47 01:49 22:24 04:32 02:47 04:23 02:47 15:28 23:51 08:23 08:23 08:23 08:23 02:47 07:47 02:47 16:11 16:11 05:31 05:31 23:36 22:24 02:47 22:24 22:24 22:24 02:47 23:44 18:14 07:47 01:02 02:47 02:47 22:24 02:47 22:24 08:18 22:24 16:28 18:10 23:44 22:24 22:24 05:03 16:28 22:24 16:43 07:47 22:24 23:58 23:44 23:51 16:43 16:43 16:43 16:43 16:43 16:43 16:43 16:43 16:43 16:43

mt -> /etc/alternatives/mt mt-gnu mv nano nc -> /etc/alternatives/nc nc.openbsd netcat -> /etc/alternatives/netcat netstat nisdomainname ntfs-3g ntfs-3g.probe ntfs-3g.secaudit ntfs-3g.usermap open -> openvt openvt pidof -> /sbin/killall5 ping ping6 plymouth plymouth-upstart-bridge ps pwd rbash -> bash readlink rm rmdir rnano -> nano run-parts sed setfont setupcon sh -> dash sh.distrib -> bash sleep static-sh -> busybox stty su sync tailf tar tempfile touch true ulockmgr_server umount uname uncompress unicode_start vdir vmmouse_detect which ypdomainname zcat zcmp zdiff zegrep zfgrep zforce zgrep zless zmore 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 #define AID_SYSTEM #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define #define AID_RADIO AID_BLUETOOTH AID_GRAPHICS AID_INPUT AID_AUDIO AID_CAMERA AID_LOG AID_COMPASS AID_MOUNT AID_WIFI AID_ADB AID_INSTALL AID_MEDIA AID_DHCP AID_SDCARD_RW AID_VPN AID_KEYSTORE AID_USB AID_DRM AID_DRMIO AID_GPS AID_UNUSED1 AID_RFU1 AID_RFU2 AID_NFC 0 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 2000 2001 2002 /* traditional unix root user */ /* system server */ /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* telephony subsystem, RIL */ bluetooth subsystem */ graphics devices */ input devices */ audio devices */ camera devices */ log devices */ compass device */ mountd socket */ wifi subsystem */ android debug bridge (adbd) */ group for installing packages */ mediaserver process */ dhcp client */ external storage write access */ vpn system */ keystore subsystem */ USB devices */ DRM server */ DRM IO server */ GPS daemon */ deprecated, DO NOT USE */ RFU */ RFU */ nfc subsystem */

#define AID_SHELL #define AID_CACHE #define AID_DIAG

/* adb and debug shell user */ /* cache access */ /* 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 #define AID_NET_RAW #define AID_NET_ADMIN #define AID_MISC #define AID_NOBODY #define AID_APP

3003 3004 3005 9998 9999

/* can create AF_INET and AF_INET6 sockets */ /* can create raw INET sockets */ /* can configure interfaces and routing tables. */ /* access to misc storage */

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, 00771, 01771, 00770, 00771, 00750, 00755, 00755, 00755, 00755, 00777, 00755,

AID_SHELL, AID_SHELL, AID_SYSTEM, AID_DHCP, AID_SYSTEM, AID_ROOT, AID_ROOT, AID_ROOT, AID_ROOT, AID_ROOT, AID_ROOT, AID_ROOT,

AID_SHELL, AID_SHELL, AID_MISC, AID_DHCP, AID_SYSTEM, AID_SHELL, AID_SHELL, AID_SHELL, AID_SHELL, AID_ROOT, AID_ROOT, AID_ROOT,

"data/local/tmp" }, "data/local" }, "data/misc" }, "data/misc/dhcp" }, "data" }, "sbin" }, "system/bin" }, "system/vendor" }, "system/xbin" }, "system/etc/ppp" }, "sdcard" }, 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

} *uid = pc->uid; *gid = pc->gid; *mode = (*mode & (~07777)) | pc->mode;

if (dir) { if(plen < len) continue; if(!strncmp(pc->prefix, path, len)) continue; } /* If name ends in * then allow partial if (pc->prefix[len -1] == '*') { if(!strncmp(pc->prefix, path, len } else if (plen == len){ if(!strncmp(pc->prefix, path, len)) }

break; matches. */ 1)) break; break;

#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.txt Only in samsung/arch/arm/common: fiq_debugger.c Only in samsung/arch/arm/common: fiq_debugger_ringbuf.h Only in samsung/arch/arm/common: fiq_glue.S Only in samsung/arch/arm/common: fiq_glue_setup.c Only in samsung/arch/arm/configs: herring_defconfig Only in samsung/arch/arm/include/asm: fiq_debugger.h Only in samsung/arch/arm/include/asm: fiq_glue.h Only in samsung/arch/arm/mach-s5pv210: adc.c Only in samsung/arch/arm/mach-s5pv210: coresight.c Only in samsung/arch/arm/mach-s5pv210: cpu-freq.c Only in samsung/arch/arm/mach-s5pv210: cpuidle.c Only in samsung/arch/arm/mach-s5pv210: dev-cpufreq.c Only in samsung/arch/arm/mach-s5pv210: dev-fiqdbg.c Only in samsung/arch/arm/mach-s5pv210: dev-herring-phone.c Only in samsung/arch/arm/mach-s5pv210: herring-btlpm.c Only in samsung/arch/arm/mach-s5pv210: herring-panel.c Only in samsung/arch/arm/mach-s5pv210: herring-rfkill.c Only in samsung/arch/arm/mach-s5pv210: herring-touchkey-led.c Only in samsung/arch/arm/mach-s5pv210: herring-vibrator.c Only in samsung/arch/arm/mach-s5pv210: herring-watchdog.c Only in samsung/arch/arm/mach-s5pv210: herring.h Only in samsung/arch/arm/mach-s5pv210/include/mach: adc.h Only in samsung/arch/arm/mach-s5pv210/include/mach: battery.h Only in samsung/arch/arm/mach-s5pv210/include/mach: cpu-freq-v210.h Only in samsung/arch/arm/mach-s5pv210/include/mach: gpio-herring.h Only in samsung/arch/arm/mach-s5pv210/include/mach: media.h Only in samsung/arch/arm/mach-s5pv210/include/mach: param.h Only in samsung/arch/arm/mach-s5pv210/include/mach: pm-core.h Only in samsung/arch/arm/mach-s5pv210/include/mach: power-domain.h Only in samsung/arch/arm/mach-s5pv210/include/mach: regs-adc.h Only in samsung/arch/arm/mach-s5pv210/include/mach: regs-audss.h Only in samsung/arch/arm/mach-s5pv210/include/mach: regs-mem.h Only in samsung/arch/arm/mach-s5pv210: mach-herring.c Only in samsung/arch/arm/mach-s5pv210: pm.c Only in samsung/arch/arm/mach-s5pv210: power-domain.c Only in samsung/arch/arm/mach-s5pv210: setup-csis.c Only in samsung/arch/arm/mach-s5pv210: setup-fb.c Only in samsung/arch/arm/mach-s5pv210: setup-fimc0.c Only in samsung/arch/arm/mach-s5pv210: setup-fimc1.c Only in samsung/arch/arm/mach-s5pv210: setup-fimc2.c Only in samsung/arch/arm/mach-s5pv210: sleep.S Only in samsung/arch/arm/plat-s5p: bootmem.c Only in samsung/arch/arm/plat-s5p: dev-csis.c Only in samsung/arch/arm/plat-s5p: dev-mfc.c Only in samsung/arch/arm/plat-s5p: devs.c Only in samsung/arch/arm/plat-s5p: hr-time-rtc.c Only in samsung/arch/arm/plat-s5p/include/plat: csis.h Only in samsung/arch/arm/plat-s5p/include/plat: fb.h Only in samsung/arch/arm/plat-s5p/include/plat: fimc.h Only in samsung/arch/arm/plat-s5p/include/plat: irq-eint-group.h Only in samsung/arch/arm/plat-s5p/include/plat: irq-pm.h Only in samsung/arch/arm/plat-s5p/include/plat: jpeg.h Only in samsung/arch/arm/plat-s5p/include/plat: media.h Only in samsung/arch/arm/plat-s5p/include/plat: mfc.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-csis.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-fb.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-fimc.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-iis.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-ipc.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-keypad.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-mfc.h Only in samsung/arch/arm/plat-s5p/include/plat: regs-systimer.h Only in samsung/arch/arm/plat-s5p: irq-eint-group.c Only in samsung/arch/arm/plat-s5p: irq-pm.c Only in samsung/arch/arm/plat-s5p: pm.c Only in samsung/arch/arm/plat-s5p: setup-mfc.c Only in samsung/arch/arm/plat-s5p: systimer-s5p.c Only in samsung/arch/arm/plat-samsung: dev-hsmmc3.c

75

Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only

in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in

samsung/arch/arm/plat-samsung/include/plat: regs-otg.h samsung/drivers/char: dcc_tty.c samsung/drivers/char: s3c_mem.c samsung/drivers/char: s3c_mem.h samsung/drivers/gpu: pvr samsung/drivers/input/keyboard: cypress-touchkey-firmware.c samsung/drivers/input/keyboard: cypress-touchkey-firmware.h samsung/drivers/input/keyboard: cypress-touchkey.c samsung/drivers/input: keyreset.c samsung/drivers/input/misc: gp2a.c samsung/drivers/input/misc: gpio_axis.c samsung/drivers/input/misc: gpio_event.c samsung/drivers/input/misc: gpio_input.c samsung/drivers/input/misc: gpio_matrix.c samsung/drivers/input/misc: gpio_output.c samsung/drivers/input/misc: k3g.c samsung/drivers/input/misc: keychord.c samsung/drivers/input/touchscreen: mxt224.c samsung/drivers/input/touchscreen: synaptics_i2c_rmi.c samsung/drivers/leds: ledtrig-sleep.c samsung/drivers/media/video: s5k4ecgx.c samsung/drivers/media/video: s5k4ecgx_regs_1_0.h samsung/drivers/media/video: s5k4ecgx_regs_1_1.h samsung/drivers/media/video: s5ka3dfx.c samsung/drivers/media/video: s5ka3dfx.h samsung/drivers/media/video: samsung samsung/drivers/mfd: max8998.c samsung/drivers/misc: ak8973-reg.h samsung/drivers/misc: ak8973.c samsung/drivers/misc: akm8975.c samsung/drivers/misc: apanic.c samsung/drivers/misc: fsa9480.c samsung/drivers/misc: kernel_debugger.c samsung/drivers/misc: kr3dm.c samsung/drivers/misc: kr3dm_reg.h samsung/drivers/misc: pmem.c samsung/drivers/misc: pn544.c samsung/drivers/misc: samsung_modemctl samsung/drivers/misc: sec_jack.c samsung/drivers/misc: uid_stat.c samsung/drivers/misc: wl127x-rfkill.c samsung/drivers/net: pppolac.c samsung/drivers/net: pppopns.c samsung/drivers/net/wimax: cmc7xx samsung/drivers/net/wireless: bcm4329 samsung/drivers/power: fuel_gauge.c samsung/drivers/power: s3c_fake_battery.c samsung/drivers/power: s5pc110_battery.c samsung/drivers/power: s5pc110_battery.h samsung/drivers/regulator: max8893.c samsung/drivers/regulator: max8998.c samsung/drivers/rtc: alarm-dev.c samsung/drivers/rtc: alarm.c samsung/drivers/rtc: rtc-max8998.c samsung/drivers/rtc: rtc-s3c.h samsung/drivers/staging: android samsung/drivers: switch samsung/drivers/usb/gadget: android.c samsung/drivers/usb/gadget: f_accessory.c samsung/drivers/usb/gadget: f_adb.c samsung/drivers/usb/gadget: f_mtp.c samsung/drivers/usb/gadget: s3c_udc.h samsung/drivers/usb/gadget: s3c_udc_otg.c samsung/drivers/usb/gadget: s3c_udc_otg_xfer_dma.c samsung/drivers/video: samsung samsung/firmware: samsung_mfc_fw.bin.ihex samsung/fs: yaffs2 samsung/include/linux: akm8975.h samsung/include/linux: android_aid.h samsung/include/linux: android_alarm.h samsung/include/linux: android_pmem.h samsung/include/linux: ashmem.h samsung/include/linux: cpuacct.h samsung/include/linux: earlysuspend.h

76

Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only Only

in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in in

samsung/include/linux: fsa9480.h samsung/include/linux: gp2a.h samsung/include/linux: gpio_event.h samsung/include/linux/i2c: ak8973.h samsung/include/linux: if_pppolac.h samsung/include/linux: if_pppopns.h samsung/include/linux/input: cypress-touchkey.h samsung/include/linux/input: k3g.h samsung/include/linux/input: mxt224.h samsung/include/linux: kernel_debugger.h samsung/include/linux: keychord.h samsung/include/linux: keyreset.h samsung/include/linux: kr3dm.h samsung/include/linux/mfd: max8998-private.h samsung/include/linux/mfd: max8998.h samsung/include/linux/mfd/wm8994: wm8994_pdata.h samsung/include/linux: nt35580.h samsung/include/linux: pn544.h samsung/include/linux/regulator: max8893.h samsung/include/linux: sec_jack.h samsung/include/linux: switch.h samsung/include/linux: synaptics_i2c_rmi.h samsung/include/linux: tl2796.h samsung/include/linux: uid_stat.h samsung/include/linux/usb: android_composite.h samsung/include/linux/usb: f_accessory.h samsung/include/linux/usb: f_mtp.h samsung/include/linux: videodev2_samsung.h samsung/include/linux: wakelock.h samsung/include/linux: wifi_tiwlan.h samsung/include/linux/wimax: samsung samsung/include/linux: wl127x-rfkill.h samsung/include/linux: wlan_plat.h samsung/include/media: s5k4ecgx.h samsung/include/media: s5ka3dfx_platform.h samsung/include/net: activity_stats.h samsung/kernel/power: consoleearlysuspend.c samsung/kernel/power: earlysuspend.c samsung/kernel/power: fbearlysuspend.c samsung/kernel/power: userwakelock.c samsung/kernel/power: wakelock.c samsung/mm: ashmem.c samsung/net: activity_stats.c samsung/net/ipv4: sysfs_net_ipv4.c samsung/sound/soc/codecs: wm8994_def.h samsung/sound/soc/codecs: wm8994_herring.c samsung/sound/soc/codecs: wm8994_samsung.c samsung/sound/soc/codecs: wm8994_samsung.h samsung/sound/soc/s3c24xx: herring-wm8994.c samsung/sound/soc/s3c24xx: s3c-dma-wrapper.c samsung/sound/soc/s3c24xx: s3c-idma.c samsung/sound/soc/s3c24xx: s3c-idma.h samsung/sound/soc/s3c24xx: s5p-i2s_sec.c samsung/sound/soc/s3c24xx: s5pc1xx-i2s.c samsung/sound/soc/s3c24xx: s5pc1xx-i2s.h

77

11.5 Sample process list using ps

$ ps USER PID root 1 root 2 root 3 root 4 root 5 root 6 root 7 root 8 root 9 root 10 root 11 root 12 root 13 root 14 root 15 root 16 root 17 root 18 root 29 root 30 root 31 root 32 root 33 root 34 root 35 root 36 root 37 root 38 root 39 root 40 root 41 root 42 root 49 root 50 root 51 root 52 root 54 root 55 root 56 root 57 root 58 root 59 root 60 root 61 root 62 root 63 root 64 root 65 root 66 root 67 root 68 root 69 system 70 root 71 root 72 root 73 radio 74 root 75 media 76 bluetooth 77 root 78 keystore 80 gps 81 shell 84 root 89 system 110 system 173 root 183 PPID 0 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 1 2 75 75 2 VSIZE RSS 320 184 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 292 148 0 0 0 0 0 0 0 0 0 0 0 0 0 0 816 120 3872 352 3856 252 676 128 9260 1300 84796 19680 25036 2112 1264 136 848 252 1752 100 14380 3108 4464 208 0 0 207728 69064 106008 28668 0 0 WCHAN ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff PC 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S S NAME /init kthreadd ksoftirqd/0 watchdog/0 events/0 khelper async/mgr suspend sync_supers bdi-default kblockd/0 kseriod kmmcd kondemand/0 pet_watchdog/0 khungtaskd kswapd0 crypto/0 kapmd pvr_timer/0 vsync_workqueue sec_jack_wq irq/38-sec_head irq/167-fsa9480 mtdblock0 mtdblock1 mtdblock2 mtdblock3 mtdblock4 mtdblock5 mtdblock6 spi_gpio.3 file-storage irq/308-mxt224_ irq/173-k3g gp2a_wq kstriped kconservative/0 binder l2cap krfcommd irq/334-cypress max8998-charger irq/39-max8998/sbin/ueventd yaffs-bg-1 mmcqd yaffs-bg-1 jbd2/mmcblk0p1ext4-dio-unwrit jbd2/mmcblk0p2ext4-dio-unwrit /system/bin/servicemanager /system/bin/vold /system/bin/netd /system/bin/debuggerd /system/bin/rild zygote /system/bin/mediaserver /system/bin/dbus-daemon /system/bin/installd /system/bin/keystore /system/vendor/bin/gpsd /sbin/adbd pvr_workqueue system_server com.android.systemui iscan_sysioc

78

root 184 2 0 0 ffffffff 00000000 root 185 2 0 0 ffffffff 00000000 root 186 2 0 0 ffffffff 00000000 root 187 2 0 0 ffffffff 00000000 app_34 188 75 103132 23732 ffffffff 00000000 com.google.android.inputmethod.latin radio 192 75 110900 19488 ffffffff 00000000 nfc 193 75 98940 15308 ffffffff 00000000 app_32 196 75 139612 57312 ffffffff 00000000 app_21 229 75 151300 33340 ffffffff 00000000 wifi 247 1 2176 596 ffffffff 00000000 app_26 346 75 100420 19000 ffffffff 00000000 app_49 452 75 95880 15956 ffffffff 00000000 root 5258 2 0 0 ffffffff 00000000 root 5259 2 0 0 ffffffff 00000000 root 5260 2 0 0 ffffffff 00000000 root 5261 2 0 0 ffffffff 00000000 app_82 5404 75 124352 32100 ffffffff 00000000 app_28 5416 75 122504 22256 ffffffff 00000000 app_1 10655 75 93924 15880 ffffffff 00000000 app_28 10684 75 99540 19328 ffffffff 00000000 com.google.android.apps.maps:FriendService app_36 10692 75 95896 17544 ffffffff 00000000 com.google.android.googlequicksearchbox app_55 10864 75 100768 22024 ffffffff 00000000 app_9 10873 75 96988 20340 ffffffff 00000000 app_59 10951 75 93444 16636 ffffffff 00000000 app_25 11080 75 96556 16184 ffffffff 00000000 com.google.android.apps.uploader app_40 11089 75 96216 17948 ffffffff 00000000 app_74 11097 75 120692 29268 ffffffff 00000000 app_69 11109 75 97392 19724 ffffffff 00000000 dhcp 11129 1 860 372 ffffffff 00000000 app_22 11172 75 106524 21628 ffffffff 00000000 app_28 11193 75 107976 21668 ffffffff 00000000 com.google.android.apps.maps:NetworkLocationService root 11215 2 0 0 ffffffff 00000000 shell 11220 84 744 336 c005bfb4 afd0c3ac shell 11221 11220 900 308 00000000 afd0b45c

S S S S S S S S S S S S S S S S S S S S S

dhcp_sysioc dhd_watchdog dhd_dpc dhd_sysioc com.android.phone com.android.nfc3 com.android.launcher com.google.process.gapps /system/bin/wpa_supplicant android.process.media com.android.providers.calendar loop0 kdmflush kcryptd_io kcryptd com.gowalla com.google.android.apps.maps com.noshufou.android.su

S com.doubleTwist.androidPlayer S android.process.acore S com.disqus.Disqus S S S S S S S com.google.android.gm com.google.android.apps.plus com.facebook.katana /system/bin/dhcpcd com.google.android.music

S flush-179:0 S /system/bin/sh 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/corejunit.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 mkdir mkdir mkdir /system /data 0771 system system /cache 0770 system cache /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 write write write

/proc/sys/kernel/sched_latency_ns 10000000 /proc/sys/kernel/sched_wakeup_granularity_ns 2000000 /proc/sys/kernel/sched_compat_yield 1 /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 chown chmod write mkdir chown chmod # 5.0 write /dev/cpuctl/fg_boost system system /dev/cpuctl/fg_boost/tasks 0777 /dev/cpuctl/fg_boost/tasks /dev/cpuctl/fg_boost/cpu.shares 1024 /dev/cpuctl/bg_non_interactive system system /dev/cpuctl/bg_non_interactive/tasks 0777 /dev/cpuctl/bg_non_interactive/tasks % /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 property service adbd /sbin/adbd disabled # adbd on at boot in emulator on 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-systemserver 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.0 Created-By: 1.0 (Android) Name: res/layout/main.xml SHA1-Digest: J291fl4ABGvK1CsYgJEpeDSWEo8= Name: res/drawable-ldpi/icon.png SHA1-Digest: i7vxaosoiS+9HzKB7ZgIsXMYRLY= Name: AndroidManifest.xml SHA1-Digest: ePodAtUbXFQfUlRNPTvbdnQrXDw= Name: res/drawable-mdpi/icon.png SHA1-Digest: 7Ft/Rirt+l/JRX2KjDREScdbCZk= Name: resources.arsc SHA1-Digest: HrkO4tPxiaPdoeNDcDx9bkZfw0s= Name: classes.dex SHA1-Digest: DMvzC9dwuhlQ6AM7/A/j7d8Ls4Y= Name: res/drawable-hdpi/icon.png SHA1-Digest: Vj/qhxk8ic8FE0/kT6E3vgRJ4mE=

86

11.8 Sample CERT.SF

Signature-Version: 1.0 Created-By: 1.0 (Android) SHA1-Digest-Manifest: Z4dOkdGC2xQJTdF+PLiUTw8d8qU= Name: res/layout/main.xml SHA1-Digest: CCybDEnTwOIdsk2rYh/ebMQ2dZ4= Name: AndroidManifest.xml SHA1-Digest: hGh9ygILugOxn+ObWZxRZdhZ29g= Name: res/drawable-ldpi/icon.png SHA1-Digest: Z/yxmMxGRNbFUkjqWONvJQH5rQw= Name: res/drawable-mdpi/icon.png SHA1-Digest: iR1AGdcgDutAX/5xyl92TWcEJuw= Name: resources.arsc SHA1-Digest: Uh5cbP8vR2hxtdEJm+kXH5gdv0M= Name: classes.dex SHA1-Digest: cTs5Sx+iEZM8UOoh66Jew7J7kbI= Name: res/drawable-hdpi/icon.png SHA1-Digest: 3vv9derC/UrLpiam9i2Yo16eHXw=

87

11.9 Android Application to Test Permissions and Runtime.Exec

package org.thirdly.test; import import import import android.app.Activity; android.os.Bundle; android.os.Environment; 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
Foreign Address State 0.0.0.0:* LISTEN 0.0.0.0:* LISTEN 127.0.0.1:56000 ESTABLISHED 127.0.0.1:55999 ESTABLISHED 127.0.0.1:7777 ESTABLISHED 127.0.0.1:7777 ESTABLISHED ::ffff:74.125.71.147:443 CLOSE_WAIT ::ffff:74.125.71.104:443 CLOSE_WAIT ::ffff:74.125.71.101:443 CLOSE_WAIT ::ffff:74.125.71.100:443 CLOSE_WAIT ::ffff:74.125.71.100:443 CLOSE_WAIT ::ffff:74.125.71.100:443 CLOSE_WAIT ::ffff:107.20.160.88:443 ESTABLISHED ::ffff:74.125.71.188:5228 ESTABLISHED ::ffff:74.125.71.101:443 CLOSE_WAIT ::ffff:74.125.71.100:443 CLOSE_WAIT ::ffff:74.125.71.100:443 CLOSE_WAIT ::ffff:74.125.71.100:443 CLOSE_WAIT

# netstat -a Proto Recv-Q Send-Q Local Address tcp 0 0 127.0.0.1:7777 tcp 0 0 127.0.0.1:7203 tcp 0 0 127.0.0.1:7777 tcp 0 0 127.0.0.1:7777 tcp 0 0 127.0.0.1:56000 tcp 0 0 127.0.0.1:55999 tcp6 0 1 ::ffff:10.0.1.16:37799 tcp6 0 1 ::ffff:10.0.1.16:44067 tcp6 0 1 ::ffff:10.0.1.16:60937 tcp6 0 1 ::ffff:10.0.1.16:34032 tcp6 0 1 ::ffff:10.0.1.16:50296 tcp6 0 1 ::ffff:10.0.1.16:38326 tcp6 0 0 ::ffff:10.0.1.16:51468 tcp6 0 0 ::ffff:10.0.1.16:57346 tcp6 0 1 ::ffff:10.0.1.16:38043 tcp6 0 1 ::ffff:10.0.1.16:44053 tcp6 0 1 ::ffff:10.0.1.16:41730 tcp6 0 1 ::ffff:10.0.1.16:50187

89