When forensic triage techniques designed for feature phones are applied to smart phones, these recovery techniques return hundreds of thousands of results, only a few of which are relevant to the inves- tigation. We propose the use of relevance feedback to address this problem: a small amount of investigator input can efficiently and accurately rank in order of relevance, the results of a forensic triage tool. LIFTR is a novel system for prioritizing information recovered from Android phones. In our related paper, we evaluate LIFTR’s ranking al- gorithm on 13 previously owned Android smart phones and three recovery engines — DEC0DE, Bulk Extractor, and Strings— using a standard information retrieval metric, Normalized Discounted Cumulative Gain (NDCG). LIFTR’s initial ranking improves the NDCG scores of the three engines from 0.0 to an average of 0.73; and with as little as 5 rounds of feedback, the ranking score in- creases to 0.88. Our results demonstrate the efficacy of relevance feedback for quickly locating useful information among the large amount of irrelevant data returned by current recovery techniques. Further, our empirical findings show that a significant amount of important user information persists for weeks or even months in the expired space of a phone’s memory. This phenomenon underscores the importance of using file system agnostic recovery techniques, which are the type of techniques that benefit most from LIFTR.

Source Code: Github

Paper: Efficient Smart Phone Forensics Based on Relevance Feedback. Saksham Varma, Robert J. Walls, Brian Lynn, and Brian Neil Levine. In Proc. Workshop on Security and Privacy in Smartphones and Mobile Devices, November 2014.


DEC0DE is a system for recovering information from phones with unknown storage formats, a critical problem for forensic triage. Because phones have myriad custom hardware and software, we examine only the stored data. Via flexible descriptions of typical data structures, and using a classic dynamic programming algorithm, we are able to identify call logs and address book entries in phones across varied models and manufacturers. We designed DEC0DE by examining the formats of one set of phone models, and we evaluate its performance on other models. Overall, we are able to obtain high performance for these unexamined models: an average recall of 97% and precision of 80% for call logs; and average recall of 93% and precision of 52% for address books. Moreover, at the expense of recall dropping to 14%, we can increase precision of address book recovery to 94% by culling results that don’t match between call logs and address book entries on the same phone.

Source Code: Github

Paper: Forensic Triage for Mobile Phones with DEC0DE. Robert J. Walls, Erik Learned-Miller, and Brian Neil Levine. In Proc. USENIX Security Symposium, August 2011.

Cookies are Better with Milk

We created a Chrome extension, called Milk, to illustrate the concept of functional privacy. Milk is designed to limit cross-site tracking without reducing functionality for the user. The general idea is to restrict, or bind, cookies to the first-party site from which they were created rather than disabling cookies entirely.

Milk implements cookie binding by intercepting cookies both before they are stored and before they are sent. Imagine this simplified example using a single first-party site. When the user visits, the server responds with an HTTP Set-Cookie header instructing the browser to store a cookie. Milk will rewrite the cookie before it is stored, appending the key "!!!" to the cookie’s name. For subsequent web requests to, Milk will rewrite the HTTP Cookie header to both remove the domain-specific keys and ensure that only cookies with the appropriate key are sent back to the server.

Source Code: Github

Paper: Functional Privacy or Why Cookies are Better with Milk. Robert J. Walls, Shane S. Clark, and Brian Neil Levine. In Proc. USENIX Workshop on Hot Topics in Security, August 2012.


The current standard and open formats for forensic data describe whole disk and memory image properties, but do not describe the products of detailed investigations. We propose a simple canonical description of digital evidence provenance that explicitly states the set of tools and transformations that led from acquired raw data to the resulting product. Our format, called Digital Evidence Exchange (DEX) is independent of the forensic tool that discovered the evidence, which has a number of advantages. Using a DEX description and the raw image file, evidence can be reproduced by other tools with the same functionality. Additionally, DEX descriptions can identify differences between two separate investigations of the same raw evidence. Finally, as a standard product of tools, DEX can allow quick fabrication of tool chains either as best of breed amalgams or for tool testing. We have implemented DEX as an open source library.

Source Code: Github

Paper: DEX: Digital Evidence Provenance Supporting Reproducibility and Comparison. Brian Neil Levine and Marc Liberatore. In Proc. of DFRWS Annual Conference, August 2009.

Top Back to top