Monday, Sep 26th, 2011
Posted By Eoghan Casey

This year Eoghan Casey worked with Tim Vidas at Carnegie Mellon University and Matthew Geiger at CERT to create the DFRWS Forensics Challenge in an effort to advance forensic analysis of Android mobile devices. The winners of the challenge were Ivo Pooters, Steffen Moorrees and Pascal Arends from Fox-IT. Their submission provides a suite of utilities written in Python for extracting information from data acquired from Flash memory on Android devices. Complete results are posted on the DFRWS Web site.

The scenarios for the DFRWS 2011 Forensics Challenge were two seemingly unrelated crimes that turned out to be tightly linked with each other. The first scenario was a suspicious death and the goal of the investigation was to determine whether the victim killed himself or was murdered. The second scenario was an intellectual property theft case and the goal of the investigation was to document any evidence that intellectual property was stolen and to support termination of the suspected insider.

An interesting outcome of the challenge was that using dd to acquire data from the Android device in Scenario 1 did not copy the important information in out-of-band (OOB) areas of the YAFFS2 file system. As a result, it was not possible to reconstruct the file system. However, contestants were still able to carve out usable content from this data.

The winning submission provides a technical analysis of data structures found in memory dump from Android mobile devices and provides an Android analysis toolkit that extracts specific items and formats them in a report. Using this toolkit to perform a forensic examination of a full NAND dump of a YAFFS2 file system (such as in Scenario 2 of the DFRWS 2011 Forensics Challenge) first requires the file system to be mounted under Linux as an emulated Flash device (using nandsim).

A sample of the information extracted by the winners from the SQLite database located on the Android device in Scenario 2 (mtd8\data\com.android.providers.telephony\databases\mmssms.db) is provided here:

Much more information was extracted from both Android devices as detailed in the reports, which include an impressive graphical reconstruction of events.

(No Comments)

Tuesday, May 31st, 2011
Posted By Eoghan Casey

After six years of work, the expanded and updated third edition of Digital Evidence and Computer Crime: Forensic Science, Computers and the Internet is now complete. The 800 printed pages and one online chapter cover the methods and tools relevant to incident responders, forensic analysts, police and lawyers.

Eoghan Casey - Digital Evidence & Computer Crime, 3rd Edition

This book is divided into five parts, beginning with the fundamental concepts and legal issues relating to digital evidence and computer crime in Part 1 (Digital Forensics: Chapters 1 – 5). Part 2 of this text (Digital Investigations: Chapters 6 – 9) covers investigative aspects of digital evidence and computer crime. Part 3 of this text (Apprehending Offenders: Chapters 10 – 14) deals with specific types of investigations with a focus on apprehending offenders, including Violent Crime in Chapter 10, Sex Offenders on the Internet in Chapter 12 and Investigating Computer Intrusions in Chapter 13. Part 4 of this book (Computer Forensics: Chapters 15 – 20) begins by introducing basic Forensic Science concepts in the context of a single computer, and goes on to apply these concepts in updated chapters dedicated to networked Windows, Unix, and Macintosh computers and mobile devices. Part 5 (Network Forensics: Chapters 21 – 25) covers computer networks from an investigative perspective, focusing specifically on the Internet and performing forensic analysis on network logs and traffic.

This material provides the foundation for the more advanced companion text, the Handbook of Digital Forensics and Investigation.

Many thanks to Susan Brenner, Christopher Daywalt, Monique Mattei Ferraro, Bert-Jaap Koops, Terrance Maguire, Mike McGrath, Tessa Robinson, Bradley Schatz, Ben Turnbull and Brent Turvey for their excellent contributions to this textbook.

(No Comments)

Wednesday, May 27th, 2009
Posted By cmdLabs Staff

Here are some examples of lesser known application metadata in Microsoft Office documents that we have encountered in casework, and that we presented at the annual meeting of the American Academy of Forensic Sciences in February.

Files created using Microsoft Office applications have more metadata than many forensic practitioners realize. Word documents, Excel spreadsheets, Powerpoint presentations, and Outlook e-mail messages are essentially a file system within a file. They are structured storage files that use OLE to create the equivalent of folders (called storages) and files (called streams).

For example, consider metadata embedded within Word 2003 documents. The Summary Information metadata extracted from a Word document using Harlan Carvey’s wmd.pl Perl script is shown here:

--------------------
Summary Information
--------------------
Title : cmdLabs
Subject :
Authress : LastName FirstName
LastAuth : LastName FirstName
RevNum : 39
AppName : Microsoft Word 11.4.2
Created : 01.28.2009, 12:12:00
Last Saved : 02.05.2009, 00:36:00
Last Printed : 02.03.2009, 15:08:00

Beyond the Summary Information metadata that most forensic practitioners are familiar with and many tools can extract, Word documents also have a FILETIME value in the ROOT ENTRY header that records the last time a document was altered. This value can provide the last modified time of a document even if the timestamps in the file system or Summary Information metadata have been maliciously altered (utilities are available that make such tampering simple).

An example of this date-time stamp in the ROOT ENTRY header is provided here (2/5/2009 12:36:04 AM):

Forensic examiners should also be aware that Microsoft Office documents have embedded metadata associated with individual objects within the file, as shown here using SSView (http://www.mitec.cz/).

Excel also contains an abundance of metadata stored within its Binary Interchange File Format (BIFF5 – 8). For instance, the cells that were selected the last time a spreadsheet was saved, and the registered name that most recently opened the document with write access. Much of this metadata is accessible using BIFFView (http://b2xtranslator.sourceforge.net). A portion of the BIFFView output with the WRITEACCESS field is show here:

Reading the documented file formats of Microsoft Office files (http://msdn.microsoft.com/en-us/library/cc313118.aspx) can help forensic practitioners delve deeper into metadata, but can also be misleading and inaccurate. Therefore, it is crucial to perform controlled experiments to locate and understand the meaning of specific metadata.

(No Comments)

Friday, May 8th, 2009
Posted By cmdLabs Staff

Despite the fact that FAT is one of the earliest file systems that forensic practitioners had to deal with, there are still gaps in knowledge that result in misinterpretation and misrepresentation. A prime example of this is the create time in FAT, which is not calculated correctly by some forensic tools. This issue came up in a recently discussion I had with Geoff Fellows (http://www.f3.org.uk/modules/smartclient/client.php?id=3). Although FAT last write timestamps only have a resolution of 2 seconds, whereas the create time has a resolution of 10 milliseconds that some forensic tools fail to take into account. A difference of milliseconds can be important in some cases, and any calculations based on an incorrect representation of creation timestamps will be incorrect.

The confusion arises from the fact that FAT file systems represent create and last write timestamps slightly differently. Last write timestamps are 32 bit little-endian values, interpreted as follows:

24                 16                8                0
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Y|Y|Y|Y|Y|Y|Y|M| |M|M|M|D|D|D|D|D| |h|h|h|h|h|m|m|m| |m|m|m|s|s|s|s|s|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+

\____________/\________/\_________/ \________/\____________/\_________/
year        month      day        hour       minute       second

Take as an example the following FAT folder entry with the last write date highlighted in bold:

$ icat /dev/sdb1 353884 | xxd
0000000: 2e20 2020 2020 2020 2020 2030 004f b079 . 0.O.y
0000010: 763a 763a 0000 b579 763a a502 0000 0000 v:v:…yv:……
0000020: 2e2e 2020 2020 2020 2020 2010 004f b079 .. ..O.y
0000030: 763a 763a 0000 b079 763a 6605 0000 0000 v:v:…yv:f…..
0000040: 4173 0061 006c 0076 0065 000f 009e 6e00 As.a.l.v.e….n.
0000050: 6500 7700 3400 2e00 6700 0000 6900 6600 e.w.4…g…i.f.
0000060: 5341 4c56 454e 7e31 4749 4620 0075 78b9 SALVEN~1GIF .ux.
0000070: 753a 763a 0000 78b9 753a 9212 c1d4 0000 u:v:..x.u:……
0000080: 4269 0066 0000 00ff ffff ff0f 0014 ffff Bi.f…………
0000090: ffff ffff ffff ffff ffff 0000 ffff ffff …………….

Converting to big-endian gives 3a 75 b9 78, which has the following binary representation:

00111010 01110101 10111001 01111000

This translates to a timestamp of 2009.03.21 23:11:48 as follows:

• 7 bits = 0011101 = 29 years since 1980
• 4 bits = 0011 = 3 months
• 5 bits = 10101 = 21 days
• 5 bits = 10111 = 23 hours
• 6 bits = 001011 = 11 minutes
• 5 bits = 11000 = 24 = 48 seconds

Note that 5 bits cannot store all 60 seconds, so last write timestamps must be incremented in 2 second intervals, and is always an even number of seconds.

Although the create time follows this same general calculation, it uses an additional 8 bits to represent one hundredths of a second. In the same directory listing above, the create timestamp is identical to the last modified timestamp except for an additional byte (75 78 b9 75 3a). The additional byte equates to 117 hundredths of a second, which brings the create time to 2009.03.21 23:11:49.17. Thus, the create time can have odd number of seconds, and has a resolution of 10 milliseconds.

Older versions of XWays Forensics had the option to display timestamps to tenths of a second, and newer versions can be configured with greater precision as shown here:

Note: Updated configuration screenshot showing increased precision in XWays 15.1 SR3 provided by Geoff Fellows.

The create timestamps for files copied onto a thumb drive are shown here in XWays Forensics with tenths of seconds displayed:

However, some other forensic tools like TSK only interpret the first four bytes of the create date-time stamp, limiting the resolution to 2 seconds. This is demonstrated in the following listing of the same files as those listed above using XWays (we have reported this bug and it will be fixed in the next release of TSK).

$ fls -l /dev/sdb1 353884 | awk {‘print $3 “\t“ $10 “\t“ $11 “ “ $12′} | sort –key 2
snake_oil.jpg 2009.03.21 23:03:32 (EDT)
orange-Clark_Stanley_Snake_Oil.png 2009.03.21 23:04:32 (EDT)
orange-OilKingLrg.jpg 2009.03.21 23:04:48 (EDT)
orange-Drs_Mixer.jpg 2009.03.21 23:05:24 (EDT)
orange-Hostetters_Bitters.jpg 2009.03.21 23:05:42 (EDT)
orange-wine_of_tar.jpg 2009.03.21 23:05:54 (EDT)
orange-medsh17.jpg 2009.03.21 23:06:04 (EDT)
orange-miraclecure.jpg 2009.03.21 23:06:14 (EDT)
snakeoil.jpg 2009.03.21 23:07:22 (EDT)
snake-oil2.jpg 2009.03.21 23:08:16 (EDT)
banjsalv.jpg 2009.03.21 23:11:30 (EDT)
salvenew4.gif 2009.03.21 23:11:48 (EDT)
yankdcornsalvelg.jpg 2009.03.21 23:12:36 (EDT)
liniment-for-man-and-beast.jpg 2009.03.21 23:12:50 (EDT)
Thumbs.db 2009.03.22 14:25:12 (EDT)

This issue was recently fixed in EnCase version 6.12, and is documented in the release note as “339: EnCase does not read FAT Create Date correctly (BUGID67).” EnCase version 6.12 now displays the create time to the correct second but not the hundredth of a second.

If a forensic examiner is not aware of this error, it can not only introduce inaccuracies into his/her findings, it can also reflect poorly on his/her expertise in this area.

The fact that this bug has existed in EnCase and other widely used forensic tools clearly demonstrates the need to validate important findings using more than one tool. Furthermore, this issue demonstrates that forensic practitioners cannot simply push buttons and unquestioningly rely on the results, but rather must understand the underlying technology sufficiently to double check what their tools are reporting.

Another area relating to FAT file systems where current literature is incorrect is in file allocation strategies but that discussion is for another time…

(No Comments)