Smartphone applications are frequently incompletely vetted, poorly isolated, and installed by users without restraint. Smartphone research frequently needs to understand how these applications behave. ded is a project which aims at decompiling Android applications. The ded tool retargets Android applications in .dex format to traditional .class files. These .class files can then be processed by existing Java tools, including decompilers. Thus, Android applications can be analyzed using a vast range of techniques developed for traditional Java applications.
For information regarding obtaining and using ded, please visit siis.cse.psu.edu/ded.
As part of theh ded project, we developed custom static analysis rules for the (now HP) Fortify Static Code Analyzer (SCA) tool. These rules test for a breadth of security vulnerabilities and dangerous functionality, as described in our USENIX Security paper. The specific rules are explained in more detail in our Technical Report. The final Fortify SCA ruleset used for this paper is available at the below link.
The TaintDroid project provides realtime analysis to watch how applications use different types of privacy sensitive information. TaintDroid uses dynamic taint analysis to track taint markings assigned to data when it is accessed from application programming interfaces. When information leaves the phone's network interface, TaintDroid records any present taint markings. To provide realtime analysis on smartphones, TaintDroid has a carefully designed architecture, trading tracking granularity for performance.
For information regarding obtaining and building TaintDroid, please visit appanalysis.org.
XATTR Support for YAFFS2
During my research with the Android smartphone platform, I've needed to store security information in XATTRs. Unfortunately, Android uses the YAFFS2 NAND file system on many of its devices, and YAFFS2 doesn't support XATTRs out of the box. The following patch is my implementation of XATTR support for YAFFS2.
The Android boot.img file contains a kernel and a ramdisk. While researching Android, I've needed to manipulate the ramdisk of a phone. I created the split_bootimg.pl script to parse the boot.img file format and extract the parts.
The following example uses the boot.img from the full TC4-RC28 update:
% ./split_bootimg.pl boot.img Page size: 2048 (0x00000800) Kernel size: 1388548 (0x00153004) Ramdisk size: 141518 (0x000228ce) Second size: 0 (0x00000000) Board name: Command line: no_console_suspend=1 Writing boot.img-kernel ... complete. Writing boot.img-ramdisk.gz ... complete.
Extract the ramdisk.
% mkdir ramdisk % cd ramdisk % gzip -dc ../boot.img-ramdisk.gz | cpio -i % cd ..
Make any changes necessary (e.g., set ro.secure=0 in default.prop).
Recreate the cpio archive using the mkbootfs binary produced from building the Android source code (The cpio utility in OS X does not recognize the newc format, therefore mkbootfs is the best option for OS X users).
% mkbootfs ./ramdisk | gzip > ramdisk-new.gz
Recreate the image file using the mkbootimg binary produced from building the Android source code.
% mkbootimg --cmdline 'no_console_suspend=1 console=null' \ --kernel boot.img-kernel \ --ramdisk ramdisk-new.gz \ -o boot-new.img
- For Nexus One: Add --base 0x20000000 to mkbootimg command-line.
- The console=null command line option was introduced in the TC4-RC30 boot images to remove the root shell
- Do not use a boot.img image extracted directly from /dev/mtd/mtd2. This image may become corrupted during the read process.