Android village @nullcon 2012


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Android founders:Andy Rubin (co-founder of Danger)Rich Miner (co-founder of Wildfire Communications, Inc.)Nick Sears (former VP at T-Mobile)Chris White (headed design and interface development at WebTV)
  • Refer to :
  • The ChallengeAndroid was designed to be truly openDesigned with developers in mind. Security controls were created in a simple way to reduce the burden on developersNew developers protected by safe defaults. Advanced developers free to experiment.The SolutionMulti-layered security framework. Allows flexibility and open as well as protects users.Android can be configured to accept a user-supplied password before granting access to devices. Apart from preventing unauthorized use of the device, this password is also used to protect the key used for fullsystem encryption in later releases.Each application runs in an isolated environment.Note: The sandbox is based on separation of Linux processes and user ids for each application. The Dalvik VM is not a sandbox. However, even native code is constrained by the sandbox.ADDITIONAL FEATURESMemory Management Security Enhancements (from includes many features that make common security issues harder to exploit. The Android SDK, compilers, and OS use tools to make common memory corruption issues significantly harder to exploit, including:Address Space Layout Randomization (ASLR) to randomize key locations in memoryHardware-based No eXecute (NX) to prevent code execution on the stack and heapProPolice to prevent stack buffer overrunssafe_iop to reduce integer overflowsExtensions to OpenBSDdlmalloc to prevent double free() vulnerabilities and to prevent chunk consolidation attacks. Chunk consolidation attacks are a common way to exploit heap corruption.OpenBSDcalloc to prevent integer overflows during memory allocationLinux mmap_min_addr() to mitigate null pointer dereference privilege escalationFor an overview of all the security features please visit:
  • 1. Hardware-based encryption implemented on tablets from v3.0 onward.2.Android v2.3 onwards makes provisions for a Never-eXecute (NX) / noexec flag.noexec flags enforced on supporting hardware (like Nexus S) enforce memory executable permissions.
  • 2.2 (Froyo)Improved enterprise security policy enforcement with the addition of numeric pin and alphanumeric passwords.Remote wipe facilityintroduced.Creation of device policy management APIs Improved performance (by a factor of 5 on most benchmarks) due to Dalvik JIT.Improved memory reclaim leads to faster app switching on memory-constrained devices.2.3 (Gingerbread)Hardware-based No eXecute (NX) to prevent code execution on the stack and heap3.0 (Honeycomb)Added support for full filesystem encryption.Details here: (Ice Cream Sandwich)ABOther Security MeasuresThe Kill SwitchBouncerAntivirus Apps (Lookout, AVG Technologies, Avast!, F-Secure, Kaspersky, McAfee and Symantec)For a security overview:
  • Associated MIME type : application/
  • Special files AndroidManifest.xml Classes.dex META_INF directoryaaptjavacdxapkbuilderjarsigneradb Package Manager (also cover setInstallLocation) Non-code resources are generally XML, PNG or JPEG files. Although initially externalized from the source code, they are compiled into a fast-loading binary format. Strings are also compressed into an efficient storage method. R is an auto-generated Java subclass that holds identifiers to non-code resources. Allows you to refer to all the resources defined in your project.AndroidManifest.xml : Required for every Android app. Describes metadata, global values and provides a definition as to the nature of the app’s components (public/private, access control for each component etc.). Besides declaring your application's Activities, Content Providers, Services, and Intent Receivers, you can also specify permissions in AndroidManifest.xml. .dex is short for Dalvik Executable. A tool called dx is used to convert some (but not all) Java .class files into the .dex format. Multiple classes are included in a single .dex file. Duplicate strings and other constants used in multiple class files are included only once in the .dex output to conserve space. Java bytecode is also converted into an alternative instruction set used by the Dalvik VM. An uncompressed .dex file is typically a few percent smaller in size than a compressed .jar (Java Archive) derived from the same .class files.A Detailed Look at the Build ProcessThe build process involves many tools and processes that generate intermediate files on the way to producing an .apk. If you are developing in Eclipse, the complete build process is automatically done periodically as you develop and save your code changes. If you are using other IDEs, this build process is done every time you run the generated Ant build script for your project. It is useful, however, to understand what is happening under the hood since much of the tools and processes are masked from you. The general process for a typical build is outlined below:The Android Asset Packaging Tool (aapt) takes your application resource files, such as the AndroidManifest.xml file and the XML files for your Activities, and compiles them. An is also produced so you can reference your resources from your Java code.The aidl tool converts any .aidl interfaces that you have into Java interfaces.All of your Java code, including the and .aidl files, are compiled by the Java compiler and .class files are output.The dex tool converts the .class files to Dalvik byte code. Any 3rd party libraries and .class files that you have included in your project are also converted into .dex files so that they can be packaged into the final .apk file.All non-compiled resources (such as images), compiled resources, and the .dex files are sent to the apkbuilder tool to be packaged into an .apk file.Once the .apk is built, it must be signed with either a debug or release key before it can be installed to a device.Finally, if the application is being signed in release mode, you must align the .apk with the zipalign tool. Aligning the final .apk decreases memory usage when the application is running on a device.
  • A complete list of tools can be found here: ( ( ( ( ( Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.A daemon, which runs as a background process on each emulator or device instance.Android ships with a debugging tool called the Dalvik Debug Monitor Server (DDMS), which provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more.
  • To learn to use various GUI controls, refer to:
  • Developer Tutorials:
  • Find more info on
  • More info : Setting up the environment : Debugging tools : Android Applications :
  • Some examples of what the Android Security Team believes to be malicious software is any application that:uses a bug or security vulnerability to gain permissions that have not been granted by the usershows the user unsolicited messages (especially messages urging the user to buy something);resists (or attempts to resist) the user's effort to uninstall it;attempts to automatically spread itself to other devices;hides its files and/or processes;discloses the user's private information to a third party, without the user's knowledge and consent;destroys the user's data (or the device itself) without the user's knowledge and consent;impersonates the user (such as by sending email or buying things from a web store) without the user's knowledge and consent; orotherwise degrades the user's experience with the device.
  • ROM:The system partition contains Android's kernel as well as the operating system libraries, application runtime, application framework, and applications. This partition is set to read-only and is what Android users/developers refer to as the ROM. 
  • Android village @nullcon 2012

    2. 2. WHOAMI
    3. 3. TOPICSDay 1 : Basics Day 2 : Advanced • Android Architecture • Malware Analysis and Design • Operating System Overview • Exploits survey • File system Overview • Common malware samples • Security Model • Detection, prevention and cure • Developer Overview • ROM cooking • Application Components • Rooting basics • Application Structure • Simple Mods • The SDK and Android Tools • Mid-range Mods • Developing a basic • Hardcode Cooking application • Advanced Pentesting and • Intro to PenTesting Forensics • Setting up the environment • Black Box PT • Reverse Engineering
    4. 4. Android Arrives• Android Inc. founded in 2003 in Palo Alto, California by Andy Rubin, Rich Miner, Nick Sears and Chris White.• Acquired in August 2005 by Google Inc. Key employees retained.• Design continued on a Linux powered mobile device. Marketed by Google to carriers as a flexible and easily upgradable OS.• On November 5, 2007, a consortium of mobile operators, software companies commercialization companies, semiconductor companies and handset manufacturers formed the Open Handset Consortium, with the stated aim of developing open standards for mobile devices.• On the same day, they released their first product ….• …. Android.
    5. 5. Android – An Introduction • A software stack for mobile devices. • Linux-based kernel. • Middleware, libraries and APIs in C. • Java-based application framework. • Custom Dalvik virtual machine with a JIT Java compiler. • Applications coded primarily in Java.
    6. 6. Android – An Introduction
    7. 7. ANDROID ARCHITECTURE (FILESYSTEM OVERVIEW) •Android Devices generally contain the following mounts / ro The root. Cannot be accessed in normal scenarios. /system ro Contains the core binaries and enforced APKs /data rw Contains installed packages /proc rw /mnt/sdcard rw SD Card mount location /mnt/sdcard/asec rw Secure storage for APKs on SD Card
    8. 8. ANDROID ARCHITECTURE (FILESYSTEM OVERVIEW) • Some important folders on a typical Android device: /system/app ro /system/framework ro /data/app rw /data/data rw /sdcard/asec rw
    9. 9. Android - Security Model – The Good• Traditional Access Control Idle-time/ one-click phone locking• Isolation (Sandboxing) Every application runs within its own VM, and each VM is in a unique Linux process. No process can access the resources of any other process.• Permissions based access control (Application-defined and user-granted) Developer configured whitelist for accessing Android and 3rd party resources. Can also enforce permissions preventing unauthorized components from executing app.• Application Provenance Applications signed using a X509 digital certificate. $25 charge for uploading app onto Android market.
    10. 10. Android - Security Model – The Bad• No hardware-based encryption• No non-executable memory area• Limited Developer Accountability• Poor Code Obfuscation options• Applications can easily be ‘trojanized’• Difficult environment for anti-virii• Long Patch cycle• Recovery/Boot process• Security enforcement reliant on end-users
    11. 11. Android - Security Model – Updates• 2.2 (Froyo) • Built-in remote wipe capability. • Built-in 4-digit-pin and alphanumeric password options for enterprise security. • Enterprise security additions like remote-wipe, device admin and password protect.• 2.3 (Gingerbread) • In certain architectures (ARMv6), Android supports non-executable pages by default including non-executable stack and heap using an eXecute Never bit.• 3.0 (Honeycomb) • Android after 3.0 provides full filesystem encryption• 4.0 (Ice Cream Sandwich) • Introduced face-unlock
    12. 12. Android Applications - An Introduction• Android installables are known as Application File Packages (APKs)• ZIP-formatted packages based on the jar file format• An APK is a collection of components. The components share certain resources.• These include a Linux process, a JVM, SQLite DBs, Shared Preferences, a File Space…• An APK also contains a store of other non-code resources
    13. 13. Android Applications - Structure
    14. 14. Android Applications – The SDK• Includes a vast array of development tools.• The officially supported IDE is Eclipse using the Android Development Tools Plugin. *You may also use any text editor along with various command-line tools to build and debug apps as well as connect to an emulator/device.• ADT includes a suite of tools that can be easily integrated with Eclipse’s IDE. Some important ones are.: • adb • android • DDMS • emulator • logcat • ProGuard• ADT controls synchronizes all the above tools with as many devices (real/virtual) as you can connect to.
    15. 15. Android Applications – Building a sample app [THE COMPONENTS]• Activities • Responds to broadcast intents • UI component for one focused task. • Must be declared in manifest/code • Usually a single screen in your app. • Stack-based lifecycle • Content Providers • Manages Persistent Data• Services • Publishes it to other apps • Long-lived worker code. No UI. • Can be connected to using Binder. • Shared Preferences • Persistent data stored as name-value• Intents pairs • Mechanism for IPC. • Defined using an Action/data pair • Uses-Permissions • Describes permissions used by your app• Intent Filters • Describes what intents a comonent can • Permissions handle • Restricts access to your components • Registers activities/services/receivers.
    16. 16. Android Applications – Building a sample app [GUI BUILDING]• Layouts are defined in XML (similar to Swing)• In Android, we implement the Activity interface in Java.• We need to overwrite a single function, i.e. onCreate()• XML layouts are later expanded into Java to generate a UI.• This is done using setContentView(• Any controls defined in your XML layouts can be referred to in Java by their ids using the findViewById() function.• For each view, a set of event listeners and responders can be defined.
    17. 17. Android Applications – Building a sample app [COMMON ERRORS]• Build path error.• AAPT unable to parse• Invalid Imports• Component unimplemented in manifest• Attempting to access without taking the required permissions• Expired debug certificate
    18. 18. Mobile Application Penetration Testing Web Application Testing Mobile TestingApplication/Business Logic not App stored in the device.present locally.No database present locally. Except App do store some data in device tocookies,cache increase the performance.All apps run in browsers Need to install emulators for each platformReversing not Applicable Applicable as installable is inside the device itself. Read more
    19. 19. Android – Setting Up a PT Labo Setting up the environment o Using proxy tools o Using Echomirage o Using Autoproxyo Android Debugging tools o adb o Ddmso Reversing Android Apps o apktool, baksmali, dex2jar
    20. 20. TOPICSDay 1 : Basics Day 2 : Advanced • Android Architecture • Malware Analysis and Design • Operating System Overview • Exploits survey • File system Overview • Common malware samples • Security Model • Detection, prevention and cure • Developer Overview • ROM cooking • Application Components • Rooting basics • Application Structure • Simple Mods • The SDK and Android Tools • Mid-range Mods • Developing a basic • Hardcode Cooking application • Advanced Pentesting and • Intro to PenTesting Forensics • Setting up the environment • Black Box PT • Reverse Engineering
    21. 21. Android Threat Model THREATS VULNERABILITIES• Remotely Infect via Market/Browser • Insecure storage • Privilege escalation attacks • Insecure IPCs • User tracking • Insecure component starting • Data stealing • Insecure WebKit • Resource misuse MALWARE FOR THE FUTURE Botnet Capabilities Application Harvesting Key Loggers
    22. 22. Android Malware facts•Reports say that chances of an android phone being compromised is 2.5 times morethan any other platform.•Count of new Android-specific malware moved to number one, with J2ME (JavaMicro Edition), coming in second while suffering only a third as many malware.
    23. 23. Android Malware•Increase in for-profit mobile malware, including simple SMS-sending Trojans andcomplex Trojans that use exploits to compromise smartphones•Mobile threats already take advantage of exploits, employ botnet functionality, andeven use rootkit features for stealth and permanence.•Maliciously modified apps are still a popular vector for infecting devices: Modify alegitimate app or game and users will download and install malware on theirsmartphones by themselves.
    24. 24. Android- Popular Malware AppsFalling DownSuper GuitarSoloSuper History EraserPhotoEditorSuper RingtoneMaker ChessSupersexPositions HotSexyVideos FalldownFallingBallDodge Scientific Calculator Dice RollerAPPUninstaller Funny Paint SpiderManAdvancedCurrencyConverter
    25. 25. Android- Popular Malware The Android/DrdDream infected over 50+ apps in google market. Included root exploits and installed one more application in system/app. It uses DES to encrypt the data it sends to the attacker. The Android/DroidKungFu family is similar to Android/DrdDream; it also uses a pair of root exploits to maintain itself on a device.The exploits are actually identical to those used by the Android/DrdDream except they have been encrypted with AES. These variants can also load URLs and install additional software and updates.
    26. 26. Android- Exploits KillingInTheNameOf  Affected Android <= 2.2  Remapped Android property space to writable  Vulnerability in Ashmem implementation  Applications having permissions to change shared properties.  Toggled property to 0  ADB Daemon now runs as root  Physical local root through ADB shell
    27. 27. Android- Exploits RageAgainstTheCage  Affected Android <= 2.2  ADBd initially runs as root and use setuid() to move to uid shell  If NPROC resource limit is reached for uid shell,  setuid() from uid root to uid shell will fail  If setuid() fails, ADBd continues running as root  If ADBd runs as root, ADB shell also runs as root  Fork()’s processes as shell user until NPROC is reached  Restart ADBd (bringing uid shell to NPROC-1) and
    29. 29. AGENDA Custom v/s stock Types of Modding  Simple Mod : GUI element modding + automated  Mid level mod : decompiling, reversing.  Hard Core : cross compiling, drivers modding Rooting Fundamental’s How Exploits Work
    30. 30. CUSTOM ROM V/S STOCK ROM Stock Rom are build for generic usage and large masses, they are non rooted by default. Custom ROMs  can have variants like  Gaming ROM  Battery Saver  Overclocking, Undervolting etc.  Bleeding edge  Pre-Rooted
    31. 31. SIMPLE MODDING Removing unnecessary /system/app  More free space.  Faster system (low ram consumption) Adding general usage applications as system app.  Disadvantage : your updates will take dual space. Removing/replacing av files, animation etc Changing the GUI elements.
    32. 32. Simple ModdingDEMO TIME
    33. 33. MID LEVEL MODDING This is where we start getting serious  Application decompiling and reversing to modify default behavior of application. Application will include CORE Applications also. Focus area’s  /system/app  /system/framework
    34. 34. Mid Level ModDEMO TIME
    35. 35. HARD CORE MOD This is where we start getting serious  Application decompiling and reversing to modify default behavior of application. Application will include CORE Applications also. Focus area’s  /system/app  /system/framework
    36. 36. Simple ModdingDEMO TIME
    37. 37. HOW ROOTING WORKS Simplest Allow user to have root access  Temporary and  Permanent Temporary root, Exploit an application gain root access Permanent make abover condition permenent by installing a backdoorr SU and SUPERUSER.apk Review su source code
    38. 38. Questions?
    39. 39. CONTACT US Anant Srivastava Mob – Email – Blog – Ankur Bhargava Mob – 9538995298 Email – Blog – Mrigesh Email –
    40. 40. Appendix : Androidisms & the Component Model• Binder  Component Framework • Ashmem  Anonymous Shared Memory• Activity UI • Pmem  Physical Memory Allocation• Service  Background Processing • ROM  Refers to /system folder• Content Providers  Data Sharing • Stock ROM  Pre-installed Android OS• Broadcast Receivers  Listener • Custom ROM Unauthorized Modded OS• Intents  IPC/ICC • Rooting  a• Manifest Metadata • ADB a• Permissions  Ensures authorization• API Levels  Separate Android Versions