Sunday, Aug 29th, 2010
Posted By Eoghan Casey

Recent research into important file formats on Windows Mobile devices has led to a breakthrough in mobile device forensics. Our improved understanding of the proprietary Microsoft embedded database format enables us to recover all available data from files such as cemail.vol, including deleted items.

The papers and associated tools detailing these advances in Windows Mobile forensic analysis are published in the Journal of Digital Investigation. The most recent special issue on forensic analysis of embedded systems contains two papers: Introduction to Windows Mobile Forensics and Windows Mobile Advanced Forensics.

Introduction to Windows Mobile Forensics by Eoghan Casey, Michael Bann and John Doyle covers the fundamentals of Windows Mobile systems, embedded database formats and tools for acquiring and examining these systems in a forensic context. A table from this paper is provided here, listing potentially useful sources of evidence on Windows Mobile devices.

Windows Mobile Advanced Forensics by Coert Klaver from the Netherlands Forensic Institute provides in-depth technical details about embedded database formats and tools for acquiring and examining this information. The author developed tools for interpreting data in embedded databases acquired from Windows Mobile devices, including deleted items.

An upcoming issues of the Journal of Digital Investigation contains the paper Windows Mobile Advanced Forensics: An Alternative to Existing Tools by Cpt. Frédérick Rehault from the French National Gendarmerie. The author developed custom boot loaders and file parsing tools to extract the maximum amount of information available from Windows Mobile devices. A small sample of the very detailed output from one customized tool is provided below, showing interpreted fields extracted from a text message in cemail.vol along with the location of associated content in the file system.

[ MESSAGE ] <<<< VISIBLE >>>>
Message Class : : IPM.SMStext
Message Flag (1:Read; 0:Unread) : 0x00000028
Subject : Love you too. Cant wait to see you tomorrow!
Msg Status : 0x00040000 : SMS
Delivery Time 2009-05-15 04:53:54
Sender Email Address : 14435551212
Sender Name : 14435551212
Last Modification Date 2009-05-15 04:53:55
Recipient Info: address & name : t£ lT SMS14105551212Steven…

-- Message Content Location --
NORMALLY Stored in "\Windows\Messaging\ 453a000a xxxxxxxx.mpb "


The tool also extracts the raw database record as shown here with all of the internal database fields:

*************************************************************
[ DEBUG ]: Found RECORD HEADER at Offset 0x000b7e9c

[ DEBUG ]: hRecord = 0x00000a47
[ DEBUG ]: hDBHandle = 0x00000060
[ DEBUG ]: DataRecordSize = 0x00b8
[ DEBUG ]: CompDataRecordSize = 0x009e
[ DEBUG ]: Nb Props found = 12
[ DEBUG ]: Flag = 0x4000 : Data might be compressed

00000000 45 0a 00 3a a0 00 00 00 0f 00 00 31 28 00 00 00 |E..:.......1(...|
00000010 00 00 b0 25 58 00 4c 00 6f 00 76 00 65 00 20 00 |...%X.L.o.v.e. .|
00000020 79 00 6f 00 75 00 20 00 74 00 6f 00 6f 00 2e 00 |y.o.u. .t.o.o...|
00000030 20 00 43 00 61 00 6e 00 74 00 20 00 77 00 61 00 | .C.a.n.t. .w.a.|
00000040 69 00 74 00 20 00 74 00 6f 00 20 00 73 00 65 00 |i.t. .t.o. .s.e.|
00000050 65 00 20 00 79 00 6f 00 75 00 20 00 74 00 6f 00 |e. .y.o.u. .t.o.|
00000060 6d 00 6f 00 72 00 72 00 6f 00 77 00 21 00 34 00 |m.o.r.r.o.w.!.4.|
00000070 00 00 04 00 00 9d b0 25 19 d5 c9 01 16 00 31 00 |.......%......1.|
00000080 34 00 34 00 33 00 35 00 35 00 35 00 31 00 32 00 |4.4.3.5.5.5.1.2.|
00000090 31 00 32 00 16 00 31 00 34 00 34 00 33 00 35 00 |1.2…1.4.4.3.5.|
000000a0 35 00 35 00 31 00 32 00 31 00 32 00 80 33 49 26 |5.5.1.2.1.2..3I&|
000000b0 19 d5 c9 01 47 0a 00 3b |....G..;|

+ List of properties in record:
-- PropID[ 0 ] = 0x80050013 UI4 : 0x3a000a45
-- PropID[ 1 ] = 0x80110013 UI4 : 0x000000a0
-- PropID[ 2 ] = 0x001a0013 UI4 : 0x3100000f
-- PropID[ 3 ] = 0x0e070013 UI4 : 0x00000028
-- PropID[ 4 ] = 0x003d001f LPWSTR :
-- PropID[ 5 ] = 0x0037001f LPWSTR : Love you too. Cant wait to see you tomorrow!
-- PropID[ 6 ] = 0x0e170013 UI4 : 0x00040000
-- PropID[ 7 ] = 0x0e060040 FILETIME 0x1c9d51925b09d00
-- PropID[ 8 ] = 0x0c1f001f LPWSTR : 14435551212
-- PropID[ 9 ] = 0x0c1a001f LPWSTR : 14435551212
-- PropID[ 10 ] = 0x30080040 FILETIME 0x1c9d51926493380
-- PropID[ 11 ] = 0x80010013 UI4 : 0x3b000a47

cmdLabs covers forensic analysis of Windows Mobile and other mobile devices in the course we develop and teach for SANS (FOR563 – Mobile Device Forensics).

(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)