Final Submission

There are two important deadlines for the project:
  • Project submission: November 9th
  • Report submission: November 12th
Instructions for the project submission. Students must submit the source code of their projects, along with additional material that students may deem necessary (e.g., documentation, configuration files, usage examples, etc.). All this material must be properly cleaned up (e.g., delete temporary files and binaries) before being compressed and packaged into a single file. This file must then be uploaded to Fenix. Please stick to using ZIP or TGZ formats; DONT'T USE RAR! If the code exceeds the maximum size accepted by Fenix, it is possible to save that package on an external hard drive / pen drive and hand it in at the reception of Tagus Park / INESC-ID Alameda until the time limit for the project submission. Note that if you decide to submit the project in this way, make sure that the hardware is properly identified with the name and number of all elements of the group. The hardware will be returned to the group after the discussions have taken place.

Instructions for the report submission. Students must write a report of the project. The page limit of the report is 5 pages, formatted according to the the SIGPLAN template and must indicate at least: (1) title of the project, (2) group number, (3) name and number of authors, (4) introduction describing the motivation of the work and the objectives of the work, (5) description of the architecture of the system which may include a presentation of its components, functionality, and algorithms / protocols of your solution, (6) description of implementation details of the project, (7) description of the evaluation methodology and evaluation results, and (8) conclusions. In addition to these pages, it is possible to append additional anexes that you may find relevant, e.g., bibliographical references, detailed diagrams, etc. Note that the information contained in the anexes won't be considered crucial for understanding the paper; therefore, the faculty won't be obliged to read it. In other words, ALL important details and findings of the project must appear in the main body of the report (i.e., within the first 5 pages). The report must be compiled in Latex and the format of the file to be submitted is PDF.

Instructions for the project demonstration. Each group must prepare a demo that showcases all relevant functionality of its project. The demos will be performed over the week 12-16 December. Each group will be assigned a time slot of 20 min for the demo. A calendar of all demos can be found here.

Instructions for the project defense. The project discussions will be scheduled for the week 19-23 December. The duration of each discussion will be 20 min. The calendar of the discussion slots can be found here.

Project Proposal

Here's some instructions and helper information for writing the project proposal.

Content of the proposal. Each group must write a project proposal containing:
  • The name of the project / tool
  • A description of the expected functionality of the tool
  • A description of the architecture of the tool
  • Plan for the implementation of the tool
  • Plan for the evaluation
Format of the document. The project proposal has a page limit of 2 A4 pages. A template is now available for students to use.

Hints for the writing. Here's some interesting pointers which give you precious hints about writing papers:
Deadline. The proposal must be submitted by October 7th, 23:59. In the following week, lab classes will be used to discuss the submitted proposals with the faculty.

Project Ideas


This is a list of some high-level topics for your project. The project proposal must be much more specific and detailed. This list is just to provide a few interesting directions.

1. File carver

Build a file carving tool or an extension to an existing open source file carving tool. There are many different carving techniques that can be investigated as well as many specific scopes for application (e.g., file systems, emails, etc.). Furthermore, file carving can applied not only to file systems, but also to network traces and even memory dumps, e.g., to extract specific data structures from memory dumps generated by volatility. The wikipedia article on file carving provides a good starting point to learn more about the different approaches that are currently used.

[1] http://forensicswiki.org/wiki/File_Carving

2. Event collection tool

A tool that performs automated grouping/annotation of low-level events in Windows, e.g. access-time, log-file entry, to higher-level events, e.g. program start, login. The idea is to somehow help reconstruct past activities performed on a given computer by stitching together events from multiple sources (e.g., Windows Registry, Event Log, file access times, etc).

3. Stochastic forensics tool

A common security breach is data theft caused by insiders. The goal of this work is to build a forensic tool which uses stochastic forensic to obtain evidence of data theft from NTFS partitions through post-mortem analysis of the files’ access timestamps. In fact, data theft normally entails accessing a large number of files (e.g., copy entire directories or creating archive files) which tends to change the access timestamp patterns of the the accessed files. The main challenge is to perform the analysis of such patterns, and identify false positives / false negatives. The evaluation of the tool can be done through experimental testing (e.g., fabricate NTFS images with and without data exfiltration patterns and verify whether the tool can detect them). The inventor of stochastic forensics has given a nice talk at Back Hat'12 which can be found on Youtube [2].

[2] https://www.youtube.com/watch?v=0pHERTAv1OM

4. Application forensics

Build special-purpose tools to collect interesting artifacts from Windows applications, for example, Skype (file transfer), Dropbox (the app - not the web app), or others.

5. Steganalysis tool

Build a steganalysis tool aimed at detecting hidden information in specific digital media. It is possible to implement a well know algorithm (adopted in a pre-existing tool or published in a academic paper) and restrict the applicability of the tool to a specific digital media format. The tool can be evaluated experimentally using test media files generated by an existing steganographic tool.

6. Slack content extractor

Assuming that the suspect has used an anti-forensics tool to hide information somewhere in a filesystem's slack space, the idea is to develop a tool that can extract and reassemble the data from slack space. There are many slack space regions where data can be stored. Different anti-forensic tools hide data in different places and in different file systems. A possible direction is to pick an existing file hiding tool and develop your application so that it can recover the content hidden by that tool. Use that very same tool to evaluate if your application works, i.e., is able to extract the content from slack space.

7. Extension to TSK

TSK is a modular framework which allows for the development of extensions to support additional forensic capabilities. Build a module for the TSK toolkit that extends the functionality of the tool in some way. For example, is able to analyze some file system unsupported by TSK in some specific way.

8. Email tracer

The goal of such a tool is to provide as much information about the origin of a given email as possible. Assume that the tool takes as input an email header and outputs that information to the user. Ultimately, we'd like to identify the identity of the sender, and the route followed by the email.

9. Extension to open source mobile forensic projects

There are numerous open source projects out there focused on the development of forensic tools for mobile applications. There's still a lot to be done in the space of mobile forensics. Therefore, contributing to extending such tools in some useful way may turn up to be valuable.

10. Detection of Bittorrent traffic

This is a pretty challenging topic. The goal is to build a tool that can detect and collect evidence of Bittorrent traffic within a given organization. As it turns out, it is quite common that individuals use Bittorrent applications to download copyright-protected content in their workplaces. Needless to say that activities are illegal and damaging for the employer institution. The idea, then is to develop a tool that can collect and analyze the local traffic so as to identify Bittorrent flows and locate the local computer involved in that communication.

Attachments