Monday, May 30th, 2011
Posted By Eoghan Casey

Digital video is becoming a more common form of digital evidence with the increasing prevalence of video in computers, mobile devices and cameras. Digital cameras can create high quality videos, most smart phones can create videos, and the iPad2 has two cameras that can create videos. The videos created by such digital devices can be stored on removable storage media and on the devices themselves. Frequent creation and deletion of videos on these kinds of devices can result in fragments of deleted video clips that most file carving tools cannot salvage. In addition, when dealing with Flash memory dumps acquired from mobile devices, data at the physical level is often fragmented. Specialized methods and tools are needed to salvage deleted video fragments as demonstrated in this article using the contents of Flash memory acquired from a Motorola V3 (RAZR) mobile device.

File Carving Limitations

Most file carving tools require a known file header in order to salvage deleted data. For instance, to recover a deleted 3gp file, most carving tools look for the file headers such as the following.

Hex view of 3gp header in the Motorola V3 Flash memory dump

If the file is fragmented or the header is missing, the file carving approach will not salvage the deleted video successfully. In this example, a file carving tool that searched the Motorola V3 memory dump for several 3gp header signatures found two files in as shown in the audit log:

05/24/2011, 11:26:35
QuickTime 3GP (3gp), header: ftypisom
QuickTime 3GP (3gp), header: ftyp3gp
QuickTime 3GP (3gp), header: ftypmmp4
Default file size: 1024 KB
Maximum file size: 100 times (individual file type definition defaults sizes respected)

E:\Physical GSM Motorola V3 RAZR\Flex Partition 1140000-1fe0000.bin
Scope: 000000 - E9FFFF
Extensive byte-level search

9D0E80 - AD0E7F: 00001.3gp
B888F0 - C888EF: 00002.3gp

05/24/2011, 11:26:35
2 file headers were found. 2 files were retrieved.

However, the salvaged files were invalid because the original files were fragmented. Furthermore, the names and directory paths of these files were not obtained using this method, demonstrating a further limitation of file carving.

Salvaging Video Fragments

When video files are fragmented, it is necessary to consider the video file format in more detail. Fortunately, many digital video formats have a structure that can be used to find and salvage individual frames. A frame is a discrete section of the video that can have a timecode or sequence number and other characteristics that can be useful for salvaging digital video clips.

The defraser tool can be used to identify frames for several video formats in a forensic duplicate of any piece of storage media, including a removable storage card, computer hard drive and Flash dump from a mobile device. The following screenshot shows defraser used to detect video related data in the Motorola V3 memory dump.

Defraser showing video related data in the Motorola V3 memory dump

Although the defraser tool does not automatically piece together the frames into a video that can be played, it does make the frames available for manual reconstruction. With some effort, defraser may be used to combine fragmented frames into a valid video file that can be played.

As with file carving methods that rely on header signatures, the carving methods employed by defraser do not provide the filenames and directory path of salvaged video data in the context of the original file system.

File System Reconstruction

Ultimately, the most effective approach to extracting digital video files from acquired digital evidence such as a Flash memory dump from mobile device is to reconstruct the logical arrangement of data. On mobile devices, this logical structure involves the flash abstraction layer and file system. Using mobile device forensic tools such as Cellebrite Physical and XRY, it is possible to reconstruct and review logical file structure of a Flash memory dump as shown below with a 3gp video stored in an MMS related file in the Motorola V3 memory dump. Note that different tools may interpret the logical structure differently and show more files and folders, clearly demonstrating the importance of validating the results of forensic examination tools.

XRY/XACT showing the logical file system in the Motorola V3 memory dump

Cellebrite Physical showing the logical file system in the Motorola V3 memory dump

Extracting the MMS file using such a mobile device forensic tool and extracting the video content as discussed in the “Delving into Mobile Device File Systems” blog post results in a 3gp file that can be played using VLC media player.

Playing salvaged digital video using VLC Player

Examination of Salvaged Video

After salvaging digital video files it is important to review the resulting data closely for potential anomalies. For instance, using MediaInfo to extract metadata from video files shows details related to its creation and format. The following screenshot shows metadata from a 3gp video extracted from the Motorola V3 memory dump, revealing that the embedded date-time stamp was set to an incorrect date.

Metadata within a 3gp video displayed using MediaInfo

In addition, reviewing individual frames within a salvaged video file can reveal anomalies such as portions of two unrelated videos being combined into one salvage file. The following screenshot shows frames extracted from a 3gp file using DCCI Video Validator revealing footage from two unrelated video files.

Frames extracted from digital video using DCCI Video Validator

Conclusions

When a video file is fragmented or the header of a video file is overwritten, carving methods that rely on header signatures and contiguous files will not salvage video files successfully and may even incorrectly combine unrelated video fragments into a single file or fail to detect the presence of video content altogether. However, using specialized tools such as defraser, a digital investigator may be able to salvage fragments of video files and piece them together into a valid video file. This process of reconstructing video fragments is time consuming and error prone, particularly when dealing with numerous video files on a single piece of storage media or mobile device. Therefore, whenever feasible, it is preferable to reconstruct the logical arrangement of data to extract the complete content of video files. Whichever method is most effective for salvaging digital video, it is important to examine the results closely to ensure the accuracy and completeness of the resulting videos. Such a review includes inspecting embedded metadata for anomalies and reviewing keyframes for possible fragments of unrelated video footage.

(No Comments)

Monday, Aug 30th, 2010
Posted By Eoghan Casey

This year Eoghan Casey collaborated with the Netherlands Forensic Institute to create the DFRWS Forensic Challenge in an effort to advance forensic analysis of Flash memory in mobile devices. The winner of the challenge was Solal Jacob who used the open source Digital Forensic Framework, and provides some new modules specifically for parsing memory dumps of Sony Ericsson K800i devices. Complete results are posted on the DFRWS Web site.

The scenario for the DFRWS2010 Forensic Challenge involves an arms dealer named Monsieur Victor (a.k.a. “The General”) who was apprehended in the Netherlands and threw Sony Ericsson K800i in a nearby canal. The Netherlands Forensic Institute acquired data from NAND and NOR chips in the water damaged mobile device using Memory toolkit. The goal of the challenge is to recover leads relating to front companies, bank accounts and cohorts.

The winning submission provides a technical analysis of data structures found in memory dump from a Sony Ericsson K800i mobile device and provides DFF plug-ins that recover wear-leveling tables, enabling a forensic analyst to reconstruct the flash abstraction layer as shown here.

Once the desired state of memory has been reconstructed, the DFF tool can be used to interpret the partition table and file systems on the mobile device as shown here.

The resulting logical view show metadata associated with files and folders, including deleted items.

In addition, digital photographs recovered from mobile device memory can be previewed using the DFF as shown here.

An interesting outcome of the challenge was that several contestants were able to extract substantial amounts of information from the physical memory dumps without understanding the logical arrangement of blocks or the file system. The implication is that, once full physical dumps of NAND and/or NOR memory are obtained from a mobile device, simple text extraction and file carving techniques can provide significant amounts of useful information, including deleted data.

A logical acquisition created using Microsystemation’s XRY mobile device forensic tool is now available to facilitate further development such as interpretation of foreign characters. As an example, the logical view of SMS messages on the device used in the DFRWS2010 Forensic Challenge is shown here.

(1 Comment)

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)