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

Fortify SCA

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

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

% ./ 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 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

Additional Notes: