Recently, the EFF launched an initiative to collect and analyze Carrier IQ profiles, which dictate exactly what information is collected by the Carrier IQ application, and where and when it is submitted to the carrier. Jered Wierzbicki and Peter Eckersley published a great tool that converts the profiles, which are WBXML-encoded blobs, to human-readable XML.
However, not all Carrier IQ profiles are stored in this format on disk. Instead, they may be kept inside a file named “archive.img”. In this post, I describe how I reverse engineered the format used to store these profiles in order to create a tool to extract them.
Read the rest of this entry »
Since the beginning of the media frenzy over CarrierIQ, I have repeatedly stated that based on my knowledge of the software, claims that keystrokes, SMS bodies, email bodies, and other data of this nature are being collected are erroneous. I have also stated that to satisfy users, it’s important that there be increased visibility into what data is actually being collected on these devices. This post represents my findings on how CarrierIQ works, and what data it is capable of collecting.
Read the rest of this entry »
In the past few months that I’ve been involved in rooting/modding Android phones, one thing that has continually bothered me is a lack of understanding about who deserves credit in the development of a root exploit for an Android phone, which frequently leads to cases of plagiarism. In this post, I hope to give some background for those not involved in the technical side of rooting phones so they can better understand the process.
Windows 8 introduced a number of exploit mitigation features, including hardening of both the userland and kernel heaps, mitigation against kernel-mode NULL pointer dereferences, and protection against abuse of virtual function pointer tables. One feature that stood out to me appears to be designed to help mitigate exploits leveraging return-oriented programming (ROP).
Read the rest of this entry »
On request of the Samsung Admire community, I decided to root another Android phone.
The Motorola Droid 3 was released July 14, 2011, and has no public technique available to get root access. On request of some members of the Android community, I decided to audit the platform in order to root the device.
During the course of kernel exploitation (or some other form of runtime kernel modification), it is frequently desirable to be able to modify the contents of read-only memory. On x86, a classic trick is to leverage the WP (write-protect) bit in the CR0 register.
I recently reported and disclosed (at Summercon) a vulnerability in the 802.11 stack of the FreeBSD and NetBSD kernels that had some interesting properties.
On May 16, 2011, Fenghua Yu submitted a series of patches to the upstream Linux kernel implementing support for a new Intel CPU feature: Supervisor Mode Execution Protection (SMEP). This feature is enabled by toggling a bit in the cr4 register, and the result is the CPU will generate a fault whenever ring0 attempts to execute code from a page marked with the user bit.
I recently completed a round of bug hunting in Linux filesystems, where I found a series of mostly minor security issues. Filesystems are a great place to start looking for kernel bugs, since the code is relatively easy to understand and review. I discovered and reported issues in btrfs (CVE-2010-1636), ext4 (CVE-2010-2066), gfs2 (CVE-2010-1641, CVE-2010-2525), and xfs (CVE-2010-2226).