tag:blogger.com,1999:blog-50578152811943128442024-03-06T20:02:10.343+00:00Forensics from the sausage factoryI worked at the coal face of a UK computer forensics lab and performed production line forensics - day in day out - welcome to the sausage factoryDC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.comBlogger83125tag:blogger.com,1999:blog-5057815281194312844.post-62721067442789402232014-11-10T11:28:00.000+00:002014-11-10T11:28:26.156+00:00Imaging drives protected with Apple FileVault2 encryption<div dir="ltr" style="text-align: left;" trbidi="on">
<h4 style="text-align: left;">
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span></h4>
<h4 style="text-align: left;">
Recognising FileVault2 encryption</h4>
<div>
<br /></div>
<div>
Apple FileVault 2 facilitates full disk encryption and requires OS X Lion or later and OS X Recovery installed on the start up drive. It is easy to detect. In the screenshot in Figure 1 File Vault 2 is activated on the Macintosh HD volume. Note that Encase indicates that all clusters on this volume are unallocated. The other partitions visible are the EFI partition and the Recovery partition.
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-GB</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin-top:0cm;
mso-para-margin-right:0cm;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0cm;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:Calibri;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment--><!--EndFragment--><br />
<div>
<br /></div>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-left: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOcCWUu-o4erL3h9Sa1R1PEMJVoHi3Wc9t691pSqse1uHbM8JWsR3uARNk3HwqmXECZzjOk5wvIdU63kTBAXMHS96FNceWF0Ez9LHfyk2Jzv_xWI7szHvmOqUkdVVKUuhMBt-L9e74pED7/s1600/Filevault2+partition+as+seen+in+Encase.PNG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOcCWUu-o4erL3h9Sa1R1PEMJVoHi3Wc9t691pSqse1uHbM8JWsR3uARNk3HwqmXECZzjOk5wvIdU63kTBAXMHS96FNceWF0Ez9LHfyk2Jzv_xWI7szHvmOqUkdVVKUuhMBt-L9e74pED7/s1600/Filevault2+partition+as+seen+in+Encase.PNG" height="207" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">Figure 1</span></td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-GB</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin-top:0cm;
mso-para-margin-right:0cm;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0cm;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:Calibri;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment-->
<br />
<div class="MsoNormal" style="text-align: justify;">
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="MsoNormal" style="text-align: justify;">
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span></div>
<div class="MsoNormal" style="text-align: justify;">
Any Mac using FileVault2 uses the GPT partitioning scheme. In GPT LBA0 contains a protective MBR, LBA1 contains the primary GPT header and LBA2 contains the first four partition entries. Each entry is 128 bytes long and contains a Partition Type GUID, a Partition Unique GUID, the starting LBA of the partition, the ending LBA of the partition and the Partition Name.</div>
FileVault 2 partitions all have a Partition Type GUID as shown in Figure 2.<br />
<div class="MsoNormal" style="text-align: justify;">
<o:p></o:p></div>
<!--EndFragment--><br />
<div>
<span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;"><br /></span>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-left: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSxx87p9HKswAlI0WPyrTbehtHg2q05oxA-R6IdLYt6M8rd1JN8jmThJebbMToKazTrLYlrpRav8Qua_06z5o5IxrGfEqktbDNI1XaRkfqQj9xn9VnQ5QLdaLOcNofjzfOgzGC5koACbZM/s1600/Screenshot+2014-11-10+08.54.37.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSxx87p9HKswAlI0WPyrTbehtHg2q05oxA-R6IdLYt6M8rd1JN8jmThJebbMToKazTrLYlrpRav8Qua_06z5o5IxrGfEqktbDNI1XaRkfqQj9xn9VnQ5QLdaLOcNofjzfOgzGC5koACbZM/s1600/Screenshot+2014-11-10+08.54.37.png" height="60" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">Figure 2</span></td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-GB</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin-top:0cm;
mso-para-margin-right:0cm;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0cm;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:Calibri;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment-->A quick examination of LBA2 (Physical Sector 2) of the Apple hard disk can establish if any of the first four partitions has FileVault2 enabled. LBA3 contains partition information for the next four partitions and so on (GPT allows up to 128 partitions). Figure 3 shows LBA2 viewed via disk view in Encase. <br />
<br />
<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjejYA9wWmGhrtw4rDnU_mVpAfd2Xf34JIalVraMxNpQeWBs3CuYMaAUxITvoQMDHmy1Eb3Imhi6RhioEIK7awjOYTCpWadM-Gz7dYzWQeaBTev7seGoDGHxQ7N73tBgO31x3v3G9ezoRHV/s1600/Partition+Records+in+LBA2.PNG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjejYA9wWmGhrtw4rDnU_mVpAfd2Xf34JIalVraMxNpQeWBs3CuYMaAUxITvoQMDHmy1Eb3Imhi6RhioEIK7awjOYTCpWadM-Gz7dYzWQeaBTev7seGoDGHxQ7N73tBgO31x3v3G9ezoRHV/s1600/Partition+Records+in+LBA2.PNG" height="222" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><span style="font-family: Helvetica Neue, Arial, Helvetica, sans-serif;">Figure 3</span></td></tr>
</tbody></table>
<br />
<br />
<br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>EN-GB</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin-top:0cm;
mso-para-margin-right:0cm;
mso-para-margin-bottom:10.0pt;
mso-para-margin-left:0cm;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:Calibri;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment-->
<!--EndFragment--><br />
<div class="MsoNormal" style="text-align: justify;">
The second 128 byte partition
entry is<span style="mso-spacerun: yes;"> </span>highlighted in light blue.<span style="mso-spacerun: yes;"> </span>The Partition Name Macintosh HD is visible from
offset 56 within the partition entry.<span style="mso-spacerun: yes;">
</span>The first 16 bytes highlighted in darker blue detail the Partition Type
GUID but it is stored in an encoded form, therefore we can use the Decode tab
to decode it as shown in Figure 4.<o:p></o:p></div>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoB-f-MIQQEy1Mi2Ob5F40nZUMC63E0iKUNjoRce-WJBFc_cwehvCcPxbpIhSBXucgxP_AkN8hubh9tiwCzVwNbqhAPpaAsMFCmEtPRGTAxiEuZVnK3bwQdYG5Zob70Qv1IV0TwFoV9AUN/s1600/Decoded+partition+type+GUID.PNG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgoB-f-MIQQEy1Mi2Ob5F40nZUMC63E0iKUNjoRce-WJBFc_cwehvCcPxbpIhSBXucgxP_AkN8hubh9tiwCzVwNbqhAPpaAsMFCmEtPRGTAxiEuZVnK3bwQdYG5Zob70Qv1IV0TwFoV9AUN/s1600/Decoded+partition+type+GUID.PNG" height="272" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 4</td></tr>
</tbody></table>
<div class="MsoNormal" style="text-align: justify;">
<br /></div>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
The extraction of each Partition Type GUID can also be achieved used the GPT Partition Parser Enscript. This Enscript outputs to the Console as shown in Figure 5. The FileVault2 volume entry is highlighted.<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjOA_ml8G5LBCEQhCTJ6rEiUjoLLnKFvqx4UtDAv0RRDtYxWv4ulq1QC9truCfKzCa9F38IsGew1k9fjYBkXcK9NkkgHY4lNz1O9mTTYxloGlNYFbf4cOh3cxjQX1X8PUgXBstgLDLroen/s1600/GPT+Partition+Parser+Enscript+output.PNG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjOA_ml8G5LBCEQhCTJ6rEiUjoLLnKFvqx4UtDAv0RRDtYxWv4ulq1QC9truCfKzCa9F38IsGew1k9fjYBkXcK9NkkgHY4lNz1O9mTTYxloGlNYFbf4cOh3cxjQX1X8PUgXBstgLDLroen/s1600/GPT+Partition+Parser+Enscript+output.PNG" height="311" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 5</td></tr>
</tbody></table>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<br />
<br />
<h4 style="text-align: left;">
Imaging FileVault2 volumes</h4>
<div>
If the passphrase used to encrypt the volume is known, it is possible to prepare a decrypted image, using the original image containing the encrypted FileVault2 volume as the source.</div>
<div>
<br /></div>
<div>
Firstly we need to convert the Encase evidence files containing the FileVault2 volume into a bitstream raw image. Guidance Software's Simon Key has written the <a href="https://support.guidancesoftware.com/forum/downloads.php?do=file&id=1277E" target="_blank">Evidence File Converter enscript </a>to do this. This script allows you to choose the Mac DMG naming scheme for the image. Store the resulting DMG files onto an external disk formatted with a file system that your Mac computer will recognise (as an aside I use the Paragon NTFS for Mac drivers so I use NTFS).</div>
<div>
<br /></div>
<div>
Next plug your external disk containing your DMG files into your Mac (mine is running the Yosemite OS) and launch Terminal. Enter the command <b>hdiutil attach -nomount path_to_your_dmg_files </b>(tip -drag the first dmg file into the terminal window to auto populate the path).</div>
<div>
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-p93gL204guAjzZYyAqHqzieHYTFhTyMbs-kcdt_sGFZtFW9vvX2vWkrvsx66oAZIrj2yoC_1mTDcYXi-HMdk7QvZpDVNcIJdXj5ZpadOfUbKaFfmBsmjWxWUqmA30VTMGlHHqXSV6mTi/s1600/Screenshot+2014-11-10+10.17.27.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-p93gL204guAjzZYyAqHqzieHYTFhTyMbs-kcdt_sGFZtFW9vvX2vWkrvsx66oAZIrj2yoC_1mTDcYXi-HMdk7QvZpDVNcIJdXj5ZpadOfUbKaFfmBsmjWxWUqmA30VTMGlHHqXSV6mTi/s1600/Screenshot+2014-11-10+10.17.27.png" height="180" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 6</td></tr>
</tbody></table>
<div>
<br /></div>
<div>
<br /></div>
<br />
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<span style="font-family: Calibri; font-size: 11.0pt; line-height: 115%; mso-ansi-language: EN-GB; mso-ascii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-language: AR-SA; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;"><br /></span>
<br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<br />
<br />
<br />
<br />
<br />
<br />
We can see the FileVault2 volume detailed in Figure 6 at /dev/disk2s2 described as a <i>Apple_CoreStorage</i> partition. Your Mac should ask you for the passphrase to unlock the disk as shown in Figure 7.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIhol9a1mFCQZTe_lLzWmYGR_KVGa2aoMmrkDed_7J3VMnD5L-xQqqM2lD1xDos0pSHnrXgIN3A917kOtV-nTLq_dko5nudUprdVz-TApRg_Csj_OLoOc1cZpR66eZOZf4gEoUZ8_Op7a9/s1600/Screenshot+2014-11-10+10.16.08.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgIhol9a1mFCQZTe_lLzWmYGR_KVGa2aoMmrkDed_7J3VMnD5L-xQqqM2lD1xDos0pSHnrXgIN3A917kOtV-nTLq_dko5nudUprdVz-TApRg_Csj_OLoOc1cZpR66eZOZf4gEoUZ8_Op7a9/s1600/Screenshot+2014-11-10+10.16.08.png" height="172" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 7</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Once you have entered the passphrase, in the terminal enter the command <b>diskutil list</b>. We can see in Figure 8 that the disk image is listed as <b>/dev/disk2</b> and the unlocked encrypted volume is listed as <b>/dev/disk3</b> (disk0 is my Macs hard disk and disk1 is the external disk containing the converted DMG files).<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNEjhbYzPsziLhdV2TYLX8duGVLfpEUCGj9nLgWmPdSBzPKnwHzZcRaV1e1ltx4uoafufL5wqeDQVYQ7f3EG7SmuE4Bdd7RHeslrlOIcVSJye3-eZHXXDcKtZoAW1FQchMipqhuYhUWTkt/s1600/Screenshot+2014-11-10+10.54.49.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNEjhbYzPsziLhdV2TYLX8duGVLfpEUCGj9nLgWmPdSBzPKnwHzZcRaV1e1ltx4uoafufL5wqeDQVYQ7f3EG7SmuE4Bdd7RHeslrlOIcVSJye3-eZHXXDcKtZoAW1FQchMipqhuYhUWTkt/s1600/Screenshot+2014-11-10+10.54.49.png" height="491" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 8</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
All that's left to do now is image the unlocked encrypted volume /dev/disk3. In the terminal enter the command <b>sudo dd bs=1m if=/dev/disk3 of=path to your output disk/output filename.dd</b><br />
<b><br /></b>
Once the dd image is completed you can add it into your case via the add raw image option.<br />
<br />
Hope this helps someone.</div>
</div>
</div>
DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com1tag:blogger.com,1999:blog-5057815281194312844.post-62802152724137504602014-04-09T17:51:00.000+01:002014-04-09T22:31:22.499+01:00Mac OS X "Set date and time automatically"<div dir="ltr" style="text-align: left;" trbidi="on">
Just as I've found the time to write up a blog post along comes an appropriate time related subject.<br />
<br />
Recently I examined an Apple iMac running Mountain Lion. I was only given access to an image. This presented a problem because the matter under investigation relied on accurate time stamps and I had no system clock to check. I knew that by default Apple OS X (Snow Leopard through to Mavericks for certain and probably earlier versions) will <i><b><span style="color: blue;">Set date and time automatically</span></b></i> whilst connected to the internet (to allow a connection to a network time server using Network Time Protocol [ntp] ) as shown in Figure 1.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxFtLFvd1i3Z5ib6wCj9_L7kVuOfWkeG1XQZl5Vf1N-uLYSUhmKVISnZM-9ozU_Ax9eE96FUboa8uXuV5Ga3ORL01cnd78rOQrFlfyVTbxoP9G_nR2sR-IOSn-FLzqUO-tm6GebUoUMa-s/s1600/Screenshot+2014-04-09+17.18.04.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxFtLFvd1i3Z5ib6wCj9_L7kVuOfWkeG1XQZl5Vf1N-uLYSUhmKVISnZM-9ozU_Ax9eE96FUboa8uXuV5Ga3ORL01cnd78rOQrFlfyVTbxoP9G_nR2sR-IOSn-FLzqUO-tm6GebUoUMa-s/s1600/Screenshot+2014-04-09+17.18.04.png" height="357" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
The problem to overcome then was to establish where this setting was stored - I knew it would be in a <i>plist</i> somewhere - isn't everything Mac related stored in a <i>plist</i>? :-) So many <i>plists</i> so little time! A little bit of research and testing allowed me to determine exactly where the setting was stored and as a result share this with you. Figure 2 shows the <i><span style="color: blue;"><b>overrides.plist</b></span></i> in the Finder at the path <span style="color: blue; font-style: italic; font-weight: bold;">/private/var/db/launchd.db/com.apple.launchd</span>.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbiM4YpKeK1hj9NbLeSWrQtLziHEwwb-ZvjKiSC5HENXyOeNByJkwGjkBg4W-WeCVkEyY1ZRNEC0WaS02SoL6GfyDg58_54OoRuwSQJ8Jnegvh3laH98FSCAksI0jwjgzvlVEjVWbwISLZ/s1600/Screenshot+2014-04-09+17.35.53.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgbiM4YpKeK1hj9NbLeSWrQtLziHEwwb-ZvjKiSC5HENXyOeNByJkwGjkBg4W-WeCVkEyY1ZRNEC0WaS02SoL6GfyDg58_54OoRuwSQJ8Jnegvh3laH98FSCAksI0jwjgzvlVEjVWbwISLZ/s1600/Screenshot+2014-04-09+17.35.53.png" height="210" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 2</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
This plist is an xml plist so it can be read easily. Figure 3 shows this plist viewed with the Xcode Property List Editor.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuw0lQZWyFJAXvA6K1i8CYoytpzgyFBSDGfyaSUphPgHPgf2ulrvNhXCzVvOt0laOMd6arBoeUtjj1aGS-zLiYHps6YOt4TTF9w1wDeccQ3UDSambbV_JxVtAzEphWD9prZSrO7jRBNo7b/s1600/Screenshot+2014-04-09+17.33.38.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuw0lQZWyFJAXvA6K1i8CYoytpzgyFBSDGfyaSUphPgHPgf2ulrvNhXCzVvOt0laOMd6arBoeUtjj1aGS-zLiYHps6YOt4TTF9w1wDeccQ3UDSambbV_JxVtAzEphWD9prZSrO7jRBNo7b/s1600/Screenshot+2014-04-09+17.33.38.png" height="273" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
The key we are interested in is the <b><i><span style="color: blue;">org.ntp.ntpd</span></i></b> key. If the <i><b>Disabled</b></i> value is <b>true</b> <span style="color: blue; font-style: italic; font-weight: bold;">Set date and time automatically </span>is turned off.<br />
<br />
Hope this helps someone.<br />
<br />
Richard</div>
DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-123496781918138392013-12-10T11:41:00.000+00:002013-12-10T11:41:37.803+00:00Apple Safari update and fsCachedData<div dir="ltr" style="text-align: left;" trbidi="on">
Recently I have had cause to look again at how the Apple Safari web browser stores cache. Surprisingly much of what I wrote concerning <a href="http://forensicsfromthesausagefactory.blogspot.co.uk/search?q=safari" target="_blank">Safari back in 2010</a> still holds true. The introduction of OSX Lion brought some changes in that a new table <i>cfurl_cache_receiver_data </i>was created within the SQLite cache.db database and used to store the cached item as a binary large object in the <i>receiver_data </i>field. <i> </i>Previously this field was within the <i>cfurl_cache_blob_data </i>table.<br />
<br />
I have now looked at Safari version 7 running in OSX Mavericks and found that not all cached data is now stored as binary large objects within cache.db. In Figure 1 we can see a number of entries in the <i>cfurl_cache_receiver_data </i>table. A number of them contain BLOBs as expected but in entry 18109 we can see that the new field <i>isDataOnFS </i>has a value of 1 and the <i>receiver_data </i>field has a value of ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E.<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi40ZwvYeLyqo8mHwgyelWqzMX5G05Te1qC8YkIYqXXqoYl8GyaecXEKUgjGjYrYMEQ2MVxTTML07nzsWfyZOJbxvOMJ5NHjIt9GzkooiE59QA7NeR2BIrxyGgCoePbbL56ZCZbR0iyZs1U/s1600/Cache_db_sqlite.PNG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi40ZwvYeLyqo8mHwgyelWqzMX5G05Te1qC8YkIYqXXqoYl8GyaecXEKUgjGjYrYMEQ2MVxTTML07nzsWfyZOJbxvOMJ5NHjIt9GzkooiE59QA7NeR2BIrxyGgCoePbbL56ZCZbR0iyZs1U/s1600/Cache_db_sqlite.PNG" height="432" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1<br />
<br />
<br /></td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
In Figure 2 we can see that the new <i>fsCachedData </i>folder contains the file ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E.</div>
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7RZhiEeaJjknysvTeG6ZOGJfeMcYh56-vFdTtRi5hxBFsx8Zk5GlryLJqpRmNFxoI3qPpakivG0W0IZQu6eH0a2C6mx0TWgCpGaRPJ4V4nf0_5ZiMn6EJXM5dubUWit_0ZMC5peUiHXt0/s1600/Screenshot+2013-12-10+09.58.49.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7RZhiEeaJjknysvTeG6ZOGJfeMcYh56-vFdTtRi5hxBFsx8Zk5GlryLJqpRmNFxoI3qPpakivG0W0IZQu6eH0a2C6mx0TWgCpGaRPJ4V4nf0_5ZiMn6EJXM5dubUWit_0ZMC5peUiHXt0/s1600/Screenshot+2013-12-10+09.58.49.png" height="306" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 2</td></tr>
</tbody></table>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
It appears that any file 4,096 bytes and larger is now cached externally in the <i>fsCachedData </i>folder. I note that the files do not have file extensions so a file signature analysis will be required. The file name is structured like a GUID. It does not appear to be a hash of the relevant URL.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
The eagle eyed amongst my readers will have already spotted another type of entry within the <i>receiver_data </i>field in Figure 1. Figure 3 shows more of them.</div>
<div style="text-align: left;">
<br /></div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWIk4rHa1BObuIzoqCWJs_BtqigV7F-qtehy7900mVqHtev85pYp-YGQlKOoJpubSLvhDBEBRmd5LBw4QMd8sKtlErq0z4IXpomGx3bZgGRRmb_ZsfE3mnjsm3RjRi95JCfMdoD2Y6ELu0/s1600/Cache_db_sqlite2.PNG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWIk4rHa1BObuIzoqCWJs_BtqigV7F-qtehy7900mVqHtev85pYp-YGQlKOoJpubSLvhDBEBRmd5LBw4QMd8sKtlErq0z4IXpomGx3bZgGRRmb_ZsfE3mnjsm3RjRi95JCfMdoD2Y6ELu0/s1600/Cache_db_sqlite2.PNG" height="390" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3</td></tr>
</tbody></table>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
<br /><br /><br /><div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<br /></div>
<div>
.</div>
<div>
<br /></div>
<div>
It can be seen that the data in the receiver_data field has the structure '474946.................................3B'. Seasoned forensicators will recognise this data as hex and that contained within it is the header and footer of a gif file. This data is stored within the Sqlite database as a BLOB however the SQLite utilty reading the BLOB has been configured to display BLOBs less than 50 bytes in size as a string.<br /><br />Until next time.<br /><br />Richard<div style="text-align: left;">
</div>
<div style="text-align: left;">
<br /></div>
</div>
</div>
DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com1tag:blogger.com,1999:blog-5057815281194312844.post-11333010520740835682013-03-04T19:15:00.003+00:002013-03-05T08:33:53.558+00:00Location Data within JPGs<div style="text-align: justify;">
We have become accustomed to fact that many of our digital photographs have location data embedded within them, populated with a GPS receiver. This data is often utilized by the modern photo management programs such as iPhoto and could conceivably have some evidential value at some point. So where is it stored? You are probably thinking, like I was, that it was sat along with all that other Exif data, is possibly in plain text and that it would be easy to locate and retrieve. In fact there is a little more to it.</div>
<br />
In Figure 1 we can see the first part of a jpg taken with an iPhone5.<br />
<br />
<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVyCDERMaNIQNfIeRsHzQEp7PZ4CiJmGKlXeMlaZLgRGP0Iio6lz9XuddT9w-UhzclSkbVKXhSo63HgiM5yaA4S3i410L-YiTcFUpFiNdrZG9jC5XCPClRaJ8XfXOV2uFqcTBDVr2BZcPL/s1600/blog1.PNG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVyCDERMaNIQNfIeRsHzQEp7PZ4CiJmGKlXeMlaZLgRGP0Iio6lz9XuddT9w-UhzclSkbVKXhSo63HgiM5yaA4S3i410L-YiTcFUpFiNdrZG9jC5XCPClRaJ8XfXOV2uFqcTBDVr2BZcPL/s1600/blog1.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 1</td></tr>
</tbody></table>
My readers will recognize the start of the jpg header 0xFF 0xD8 0xFF etc etc but I want to draw your attention to<span style="color: white;"> <span style="background-color: red;">0x4D 0x4D</span></span> . These two bytes are the start of a section of data known as a TIFF structure and are part of an 8 byte header. <a href="http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf" target="_blank">The TIFF file specification published by Adobe</a> details the information residing in this header.<br />
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOoPiK-4GFLDgyKCq2kz_O6tDF3VWPJP7d4Y3NKESbw5dQi-vgozaL5xUUWvjc5U5GnGcZnuSkOUWLCZwwJylDgiEAfyB_Up0wLj9agiN_V2oOG91RAn6vtN6mrjQ7KXVNhivvvbkmVOjK/s1600/Blog2.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOoPiK-4GFLDgyKCq2kz_O6tDF3VWPJP7d4Y3NKESbw5dQi-vgozaL5xUUWvjc5U5GnGcZnuSkOUWLCZwwJylDgiEAfyB_Up0wLj9agiN_V2oOG91RAn6vtN6mrjQ7KXVNhivvvbkmVOjK/s1600/Blog2.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 2</td></tr>
</tbody></table>
<br />
<div style="text-align: justify;">
In ASCII these bytes are read as <b>MM</b>. These bytes indicate that where applicable the data following should be interpreted Big Endian. The MM and II references hark back to the competing Intel and Motorola technologies. Immediately following are the two bytes <span style="background-color: #ea9999;">0x00 0x2A</span><span style="background-color: white;"> which decoded as an (in this case big endian) integer have the value 42. This value 42 always follows MM or II and is part of the TIFF structure header (<em>note the HHGTTG reference).</em> The following four bytes 00 00 00 08 detail the offset (8 in this case) from the start of the TIFF structure header to the start of a structure called an IFD.</span></div>
<span style="background-color: white;"><br /></span>
<br />
<span style="background-color: white;">IFD is an <b>I</b>mage <b>F</b>ile <b>D</b>irectory. Adobe defines it as: <em>a 2 byte count of the number of directory entries (i.e. the number of fields), followed by a sequence of 12 byte field entries, followed by a 4 byte offset of the next IFD (or 0 if none).</em></span><br />
<br />
<span style="font-size: large;"><span style="font-size: small;">We can see that in this case we have <span style="background-color: #a64d79; color: white;">0x00 0x0a</span><span style="background-color: white;"> (10) 12 byte directory entries the start of each being marked in<span style="color: lime;"> </span></span><span style="background-color: lime; color: black;">green.<span style="background-color: white;"> Adobe details the structure of each entry as follows:</span></span></span></span><br />
<br />
<em><strong>Bytes 0-1 The tag that identifies the field</strong></em><br />
<strong><em></em></strong><br />
<strong><em>Bytes 2-3 The field type</em></strong><br />
<strong><em></em></strong><br />
<strong><em>Bytes 4-7 the number of values, Count of the indicated type</em></strong><br />
<strong><em></em></strong><br />
<strong><em>Bytes 8-11 The Value Offset, the file offset (in bytes) of the Value of the field</em></strong><br />
<strong><em></em></strong><br />
<div style="text-align: justify;">
The tag we are interested in within the IFD is <span style="background-color: lime;">0x88 0x25</span>. A comprehensive list of tag numbers can be found at <a href="http://www.exiv2.org/tags.html" target="_blank">www.exiv2.org/tags.html</a>. The 0x88 0x25 tag is used to store a pointer to another IFD, the GPS Info IFD. If this tag does not exist there isn't a GPS Info IFD and therefore no JPG location information (but don't forget the tag may be stored little endian 0x25 0x88). Bytes 2-3 in this directory entry are <span style="background-color: cyan;">0x00 0x04</span>. This indicates that the field type is type 4. Adobe details the possible field types as follows:</div>
<br />
<em><strong>1 = BYTE 8-bit unsigned integer. <br /><br />2 = ASCII 8-bit byte that contains a 7-bit ASCII code; the last byte must be NUL (binary zero). <br /><br />3 = SHORT 16-bit (2-byte) unsigned integer. <br /><br />4 = LONG 32-bit (4-byte) unsigned integer. <br /><br />5 = RATIONAL Two LONGs: the first represents the numerator of a fraction; the second, the denominator.</strong></em><br />
<strong><em></em></strong><br />
<div style="text-align: justify;">
We can see that the field type is 4 indicating that the value of this entry will be stored as one or more (depending on the Count) 32 bit unsigned integers. Bytes 4-7 in this directory entry are <span style="background-color: #073763; color: white;">0x00 0x00 0x00 0x01</span>. This indicates how many instances (a count) of the field type we require, in this case just 1 so this directory entry will contain only 1 32 bit unsigned integer.</div>
<br />
The remaining four bytes of any directory entry, bytes 4-7 contain an offset from the TIFF structure header to the location of the Value data. However Adobe states where the value is four bytes or less (as in this case) that:<br />
<br />
<em><strong>To save time and space the Value Offset contains the Value instead of pointing to the Value if and only if the Value fits into 4 bytes. If the Value is shorter than 4 bytes, it is left-justified within the 4-byte Value Offset, i.e., stored in the lower numbered bytes. Whether the Value fits within 4 bytes is determined by the Type and Count of the field.</strong></em><br />
<strong><em></em></strong><br />
<div style="text-align: justify;">
Our value in this example is one 32 bit unsigned integer which will fit into 4 bytes. Therefore the remaining 4 bytes in our directory entry <span style="background-color: #3d85c6; color: white;">0x00 0x00 0x02 0x5A<span style="background-color: white; color: black;"> are the value itself. You will recall that the <span style="background-color: lime;">0x88 0x25</span> tag is used to store a pointer to the GPS Info IFD. <span style="background-color: #3d85c6; color: white;">0x00 0x00 0x02 0x5A</span><span style="background-color: white; color: black;"> decoded gives us a value of 602. This indicates that the GPS Info IFD can be found at offset 602 from the TIFF Structure header. Figure 3 below shows the data at offset 602 (from the TIFF structure header, not the start of the file). We can see that the first two bytes at this offset are <span style="background-color: #a64d79; color: white;">0x00 0x09</span>. This indicates the number of 12 byte directory entries to be found in this IFD, in this case 9, the start of each marked in <span style="background-color: lime;">green</span>.</span></span></span></div>
<strong><em></em></strong><br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiziYaqFH7r5Hzoofthrw0Fy8FyNxqKF6Xn7G8tDM7NYshnYs3Gwr2hi3wjdfqGrpffXyR5gZgavgRsJYD5RMP6xmhp0WziTzJdXAFQmBqiy8TWk6ooaFMzP-lg827ntHcSswsee0V8qhe_/s1600/blog3.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="172" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiziYaqFH7r5Hzoofthrw0Fy8FyNxqKF6Xn7G8tDM7NYshnYs3Gwr2hi3wjdfqGrpffXyR5gZgavgRsJYD5RMP6xmhp0WziTzJdXAFQmBqiy8TWk6ooaFMzP-lg827ntHcSswsee0V8qhe_/s640/blog3.PNG" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 3</td></tr>
</tbody></table>
<div style="text-align: justify;">
The GPS IFD has a series of potential tag values. A comprehensive list can be found at <a href="http://www.awaresystems.be/imaging/tiff/tifftags/privateifd/gps.html" target="_blank">http://www.awaresystems.be/imaging/tiff/tifftags/privateifd/gps.html</a>. From this list we can see that the tags of most interest here are:</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<strong><u>Hex Name Description</u></strong></div>
<div style="text-align: justify;">
<strong><u></u></strong><br />
0001 GPSLatitudeRef ------ Indicates whether the latitude is north or south latitude. <br />
<br />
0002 GPSLatitude ---------- Indicates the latitude.<br />
<br />
0003 GPSLongitudeRef ---- Indicates whether the longitude is east or west longitude. <br />
<br />
0004 GPSLongitude --------- Indicates the longitude.<span style="font-family: "Courier New", Courier, monospace; font-size: x-small;"></span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<br />
<br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg79YNiZDUxrJvTSg_7lHtAPckkBBcsQhx-AKsEpvLbNE5-DLF97GosaXT06WQnYNb1y-jzcMQvgzrT1ZWYcmTiD85z4-SzusLqdXrGLROt7uUNgMHojtqFLYBdN8TTBS9T5RuZ5pdMVEwJ/s1600/blog4.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg79YNiZDUxrJvTSg_7lHtAPckkBBcsQhx-AKsEpvLbNE5-DLF97GosaXT06WQnYNb1y-jzcMQvgzrT1ZWYcmTiD85z4-SzusLqdXrGLROt7uUNgMHojtqFLYBdN8TTBS9T5RuZ5pdMVEwJ/s1600/blog4.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 4</td></tr>
</tbody></table>
<div style="text-align: justify;">
Figure 4 above shows the GPSLatitudeRef entry. <span style="background-color: lime;">0x00 0x01</span> is the tag number. <span style="background-color: cyan;">0x00 0x02</span> indicates the value is stored as ASCII. <span style="background-color: #20124d; color: white;">0x00 0x00 0x00 0x02</span> indicates how many instances of the ASCII field type we can expect, in this case two. Two ASCII characters may be stored in two bytes which means that the value itself will be stored in the leftmost bytes of the remaining four bytes of the entry. <span style="background-color: #3d85c6; color: white;">0x53</span> decodes in ASCII to uppercase <span style="background-color: #3d85c6; color: white;">S</span> followed by 0x00. The GPS LongitudeRef entry decodes in a similar fashion.<br />
<br /></div>
<div style="text-align: justify;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIzEzivWUaNd7gM5RsmegHvkZ39-ASDT7are-ywH8Jc8BkuCFUjAMu3TY7KnLbS6P-GUqmsPG1FIYMpCCoEJsVig6l8LBf5n0-9X88E6mpQm00onF5bfZRZxx1lU1QYyMgWprH6WD33ski/s1600/blog5.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiIzEzivWUaNd7gM5RsmegHvkZ39-ASDT7are-ywH8Jc8BkuCFUjAMu3TY7KnLbS6P-GUqmsPG1FIYMpCCoEJsVig6l8LBf5n0-9X88E6mpQm00onF5bfZRZxx1lU1QYyMgWprH6WD33ski/s1600/blog5.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 5</td></tr>
</tbody></table>
<div style="text-align: justify;">
Figure 5 above shows the GPSLatitude entry. <span style="background-color: lime;">0x00 0x02</span> is the tag number. <span style="background-color: cyan; color: black;">0x00 0x05</span> indicates that the type of value stored is a RATIONAL. <span style="background-color: #351c75; color: white;">0x00 0x00 0x00 0x03</span> indicates how many instances of the RATIONAL value we can expect, in this case three. RATIONALs are 8 bytes long and three of them are needed to store the required value, so the remaining four bytes of this entry <span style="background-color: #3d85c6; color: white;">0x00 0x00 0x02 0xCC</span> indicate where the value is stored offset from the start of the TIFF structure. In this case the offset is 716.<br />
<br /></div>
<div style="text-align: justify;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4dKnUlhOeMh7WbkCmZy96wk0fmJgzFtMeDRwxXCDt8YKa6a_9vB80JNJQpyB9GXN6YVWMAFNltVfaJxxMZKI94lQfKGc3afE6Hrj6NXoyC2Eevb04_b6FwWnTarF6pR_wGEA19_jVssP-/s1600/blog6.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4dKnUlhOeMh7WbkCmZy96wk0fmJgzFtMeDRwxXCDt8YKa6a_9vB80JNJQpyB9GXN6YVWMAFNltVfaJxxMZKI94lQfKGc3afE6Hrj6NXoyC2Eevb04_b6FwWnTarF6pR_wGEA19_jVssP-/s1600/blog6.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 6</td></tr>
</tbody></table>
<div style="text-align: justify;">
Figure 6 above shows the three RATIONALs at offset 716. Each RATIONAL consists of two LONGs highlighted in <span style="background-color: red; color: white;">red</span> and <span style="background-color: yellow;">yellow</span>. The first LONG represents the numerator of a fraction, the second LONG the denominator. We can decode the RATIONAL values as follows:</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"><span style="background-color: red; color: white;">0x00 0x00 0x00 0x06</span> / <span style="background-color: yellow; color: black;">0x00 0x00 0x00 0x01</span> = 6/1 = 6</span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"><span style="background-color: red; color: white;">0x00 0x00 0x05 0xFC</span> / <span style="background-color: yellow; color: black;">0x00 0x00 0x00 0x64</span> = 1532/100 = 15.32</span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"><span style="background-color: red; color: white;">0x00 0x00 0x00 0x00</span> / <span style="background-color: yellow; color: black;">0x00 0x00 0x00 0x01</span> = 0/1 = 0</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The specification for storing the latitude states: t<em>he latitude is expressed as three RATIONAL values giving the degrees, minutes, and seconds, respectively. If latitude is expressed as degrees, minutes and seconds, a typical format would be dd/1,mm/1,ss/1. When degrees and minutes are used and, for example, fractions of minutes are given up to two decimal places, the format would be dd/1,mmmm/100,0/1. </em>It can be seen here that the latitude is stored in degrees and minutes.<br />
<br /></div>
<div style="text-align: justify;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD2Vc9e0FcSczxmHskxLP-uW4MHSaGwPilFvdcfPC0PWRx3brwSx9y2DZZap65yw0XY2okv9bXzBbIkq1YsfR5FdhGE84hgOdC-zT9mjj-eyD9HLld2veIM-D1mxKzYhhsVqzMT-lw9j0H/s1600/blog7.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgD2Vc9e0FcSczxmHskxLP-uW4MHSaGwPilFvdcfPC0PWRx3brwSx9y2DZZap65yw0XY2okv9bXzBbIkq1YsfR5FdhGE84hgOdC-zT9mjj-eyD9HLld2veIM-D1mxKzYhhsVqzMT-lw9j0H/s1600/blog7.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 7</td></tr>
</tbody></table>
<div style="text-align: justify;">
Figure 7 above shows the GPSLongitude entry. <span style="background-color: lime;">0x00 0x04</span> is the tag number. <span style="background-color: cyan; color: black;">0x00 0x05</span> indicates that the type of value stored is a RATIONAL. <span style="background-color: #351c75; color: white;">0x00 0x00 0x00 0x03</span> indicates how many instances of the RATIONAL value we can expect, in this case three. RATIONALs are 8 bytes long and three of them are needed to store the required value, so the remaining four bytes of this entry <span style="background-color: #3d85c6; color: white;">0x00 0x00 0x02 0xE4</span> indicate where the value is stored offset from the start of the TIFF structure. In this case the offset is 740.<br />
<br /></div>
<div style="text-align: justify;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv6VMTaZgphG6vtjDCe-mnAlTGgVgmvIxF_KgUQtzDjX0WCQj8qutjYlb01-aoJVKnTtIB3ftsXLqNcIRBcHPpIgZAygBje9fiGTTF-FBLWv2AsxVO-3CQ-9ffz5PSRz4ZyAGAUnle3or2/s1600/blog8.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgv6VMTaZgphG6vtjDCe-mnAlTGgVgmvIxF_KgUQtzDjX0WCQj8qutjYlb01-aoJVKnTtIB3ftsXLqNcIRBcHPpIgZAygBje9fiGTTF-FBLWv2AsxVO-3CQ-9ffz5PSRz4ZyAGAUnle3or2/s1600/blog8.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 8</td></tr>
</tbody></table>
<div style="text-align: justify;">
Figure 8 above shows the three RATIONALs at offset 740. Each RATIONAL consists of two LONGs highlighted in <span style="background-color: blue; color: white;">blue</span> and <span style="background-color: yellow;">yellow</span>. It can be seen that these RATIONAL values follow those for the latitude. The first LONG represents the numerator of a fraction, the second LONG the denominator. We can decode the RATIONAL values as follows:<br />
<br /></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"><span style="background-color: blue; color: white;">0x00 0x00 0x00 0x6A</span> / <span style="background-color: yellow; color: black;">0x00 0x00 0x00 0x01</span> = 106/1 = 6</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"></span> </div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"><span style="background-color: blue; color: white;">0x00 0x00 0x12 0xFE</span> / <span style="background-color: yellow; color: black;">0x00 0x00 0x00 0x64</span> = 4862/100 = 48.62</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span></div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"></span> </div>
<div style="text-align: justify;">
<span style="font-family: "Courier New", Courier, monospace;"><span style="background-color: blue; color: white;">0x00 0x00 0x00 0x00</span> / <span style="background-color: yellow; color: black;">0x00 0x00 0x00 0x01</span> = 0/1 = 0</span><br />
<span style="font-family: "Courier New", Courier, monospace;"><br /></span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
The specification for storing the longitude states: <em>the longitude is expressed as three RATIONAL values giving the degrees, minutes, and seconds, respectively. If longitude is expressed as degrees, minutes and seconds, a typical format would be ddd/1,mm/1,ss/1. When degrees and minutes are used and, for example, fractions of minutes are given up to two decimal places, the format would be ddd/1,mmmm/100,0/1.</em> It can be seen here that the longitude is stored in degrees and minutes.</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
To confirm our findings I have used Irfan View to examine the EXIF data, the GPS data can be seen in Figure 9 below.</div>
<div style="text-align: justify;">
</div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMHwz3dvjWxLV2dMxxz638rzS7KL22MgRHNdxfyhzxL29BLawG7DEI6Z-tyToP_M6ak4OUJDKeDgmCTqME5PMfREvnbn1mTwTN-OTMe5Yf0XGwMtPOo_zIO4cp2J0mSXuC-na9Wgg9V-b3/s1600/blog9.PNG" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjMHwz3dvjWxLV2dMxxz638rzS7KL22MgRHNdxfyhzxL29BLawG7DEI6Z-tyToP_M6ak4OUJDKeDgmCTqME5PMfREvnbn1mTwTN-OTMe5Yf0XGwMtPOo_zIO4cp2J0mSXuC-na9Wgg9V-b3/s1600/blog9.PNG" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 9</td></tr>
</tbody></table>
<div style="text-align: justify;">
For the curious the actual photograph is below.<br />
<br /></div>
<div style="text-align: justify;">
</div>
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNm6w0W9Jc_LgZ6l-RQYgdYhgeP-Tne0we0pFMKEDyvJw8BBysraWma7z1WGL98QpsSAK8c_mdeGrCtjbBipJL5MxmzbAp94LVF5rAtC1ASX4bWPTonF3NDM1hKjK34gkXullQRWSHIZIm/s1600/photo-1.JPG" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="150" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhNm6w0W9Jc_LgZ6l-RQYgdYhgeP-Tne0we0pFMKEDyvJw8BBysraWma7z1WGL98QpsSAK8c_mdeGrCtjbBipJL5MxmzbAp94LVF5rAtC1ASX4bWPTonF3NDM1hKjK34gkXullQRWSHIZIm/s200/photo-1.JPG" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Figure 10</td></tr>
</tbody></table>
<div style="text-align: left;">
<span style="color: black;">The location can be viewed on a map at <a href="http://maps.google.com/maps?q=-6.255333,106.810333&z=15" target="_blank">http://maps.google.com/maps?q=-6.255333,106.810333&z=15</a></span></div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
</div>
<div style="text-align: justify;">
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong>
<strong><br /></strong><br />
<strong>References</strong></div>
<div style="text-align: justify;">
<a href="http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf">http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf</a></div>
<div style="text-align: justify;">
<a href="http://www.exiv2.org/tags.html">http://www.exiv2.org/tags.html</a></div>
<div style="text-align: justify;">
<a href="http://www.awaresystems.be/imaging/tiff/tifftags/privateifd/gps.html">http://www.awaresystems.be/imaging/tiff/tifftags/privateifd/gps.html</a></div>
<div style="text-align: justify;">
</div>
DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com3tag:blogger.com,1999:blog-5057815281194312844.post-86533695464179286502012-05-15T12:36:00.001+01:002012-05-15T12:36:00.670+01:00Windows Live Messenger – MessengerCache folder<p>A recent case was unusual because most of the <em>ipoc</em> were located by the police examiner in a folder entitled <em>MessengerCache </em>at the path <i>C:\Users\<user_name>\AppData\Local\Temp\MessengerCache.</i></p> <p>My mission was to have a closer look at how this folder is utilised by the program Windows Live Messenger. The folder is a hidden folder and is used for various purposes by WLM. I found that the folder can be used to store the user tile (this may be an icon or a thumbnail photograph or graphic) and theme picture of a remote contact. Of course the remote user (who could be anywhere in the world) can change these at any time to a contraband image. In Figure 1 below the screenshot shows the Windows Live Messenger program running upon the local user’s computer. The two photographs arrowed and labelled as <i>Remote User Tile </i>and <i>Remote User Theme Picture </i>respectively have been received from the remote user <i>Mars </i>with whom the local user is engaged in an instant messaging conversation.<i></i></p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgpVcj5LmxCYe_wjOgEifvo0_Ri_eTXcuz4YkDtKFkude-QXIXIEFUwHzZLN_LI4bSuoBlgz-2QZo0_LjTQwDwkNX47NH5Yf1W-xUG8JrMbhjLijxuCr-PVjb1ZsIEyridz-92BXyYL2xC3/s1600-h/image%25255B4%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhvLdpf_uCcy3lqi3KZTjQIW3mdUZAA6CnDAZDVkkkBbSOWOVLguTeA3_8-s4g7VJ1oLAD9PmPYGcClTou7J3dgw_MRmyeMVYNxDDYmAUOpBdEBG5r2ZNEbpTXA5R0_MbSoGZcNpOmL976j/?imgmax=800" width="296" height="318"></a></p> <p>It is also possible for a remote contact anywhere in the world whilst engaged in an instant messaging conversation with the local user to drag a picture file into the conversation window. This results in the picture concerned appearing in the local user’s conversation window in full size and thumbnail form and at the same time a copy of the picture and a thumbnail version are stored within the <i>MessengerCache</i> folder. In the case that the picture concerned was <em>ipoc</em> the local user’s only immediate option would be to close the conversation window. He would be unlikely to be aware that the photograph concerned was now stored upon his own computer in the <i>MessengerCache</i> folder. In figure 2 the screenshot shows the local user’s conversation window after the remote user <i>Mars </i>has dragged a photograph of tulips into his conversation window. This has caused the local user’s conversation window to also display the tulip pictures. The tulip photograph would also be stored in full and thumbnail versions within the local user’s <i>MessengerCache</i> folder. <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj7fp-dZvuAc-cuJ9-bGPfDpMZSoxlNnlztAJHbwAu4CYxsqpdTLpV0S8KaFfoXh8vy2JxbKUT8proP_z8FsRgSk4Yx33PF-BYW5EvACSJnpcthnKKEUg1MqYOZl3TElNuBRx63Mhz8nJsi/s1600-h/image%25255B9%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBxmRI2Xd8e1YyMBwBquJ2pOW0kcXI2DD9RDOUiulFtJWRsJpCSxbL3eNbHY4pTgI1AP6PvG77pjh_RBnb-hGXxfHsdrxPzKo21nJTKUoevyO6RbeaPz_GnkXBNVDRxbwMIjCAqNKXg79T/?imgmax=800" width="313" height="269"></a> <p>Figure 3 below illustrates a forensic examination of the local user’s <em>MessengerCache</em> folder. It can be seen that it contains the <i>Remote User Tile </i>and <i>Remote User Theme Picture </i>together with three different versions (they differ in resolution) of the Tulip picture. At this point none of these five pictures were solicited or accepted by the local user.</p> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOSGrCXpYj5K5cySZEZnpiYt7fJbiw92IxOYgZ99nhP6zv8zeq73t_Q0XD5v4h1_oZGK6e7W2ueWXH1BCFEkHJJBY2RjXPRnT63CqLc5PX1VSnWY2koN2nWsDjWZIp40qbDndLRAOYIGJB/s1600-h/image%25255B16%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOStftwpAUW2s63abWYwmzcrvW4bm7Khny1XkNzo40d6d1L5zJXXY5rXe2vQmpd8SMi_gEKNE8pJvoOTPfOd1_kajAl_OAch3bWLSu7v7ziWpJH40NILnYRGUAb2uULfl1AXDxFTUnhlrI/?imgmax=800" width="374" height="439"></a></p> <p>In the case referred to the prosecution, after discussions at court, offered no evidence in respect to all the counts on the indictment that relied on the pictures located within the <em>MessengerCache</em> folder. The defendant pleaded guilty to one count of possession not related to the <em>MessengerCache</em> pictures.</p> DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-51820708459803731722012-05-15T11:39:00.001+01:002012-05-15T11:41:00.118+01:00Old Servers never die – unfortunately<p>But you can bet your last penny that at some stage you will have to image them. That is the problem I faced one wet weekend recently when I was required to image an HP behemoth resplendent with two sizable raid 5 arrays and two USB 1 ports. All drive bays and ports were in use so I could not insert a new drive into the box to image it and I didn’t fancy imaging all the elderly SCSI raided hard drives separately. I was permitted to shut down the server and had decided to boot the box to a forensic linux distro that had suitable HP Raid Controller drivers. </p> <p>The problem I faced was USB1. Obviously I needed to output my images somewhere and an external USB hard drive was an option. But the maths didn’t add up – the maximum bandwidth of a USB1 port is 12 megabits per second (Mbps) which equates to 1.5 megabytes per second (MB/s) which equates to 5.4 Gigabytes per hour. There were not going to be enough hours in this weekend to image both arrays on the server. </p> <p>What I did next I thought might be worth sharing with you. I used <strong>dd</strong> to create a source image, <strong>netcat</strong> to pipe it to an onsite laptop across a network and <strong>ewfacquirestream</strong> to capture the <strong>dd</strong> image, hash it and write it into Encase evidence files. It can be carried out entirely at the command line. Crucially I achieved an imaging speed of about 25 MB/s which is 1.46 gigabytes a minute or nearly 88 gigabytes an hour using gigabit network interface cards. In testing I have achieved 39 gigabytes an hour using 10/100 NICS.</p> <h3>Method to image computers across a network</h3> <ol> <li>I connected my onsite laptop and the server via Cat5E cables to a Netgear GS105 5 port gigabit switch. I attached a 2TB external hard drive to my onsite laptop and booted both the server and my laptop to a <a href="http://www.deftlinux.net/" target="_blank">DEFT 7</a> forensic linux distro. <li>To configure Ethernet settings on both using Gigabit NICs (10/100/1000) if available <ul> <li>Launch terminal and at prompt type <strong>sudo su</strong> <li>At prompt type <strong>ifconfig</strong> to identify network cards <li>At prompt type <strong>ifconfig</strong> <strong>eth0 192.168.0.100</strong> on onsite laptop and<strong> ifconfig eth0 192.168.0.101</strong> on machine to be imaged (these commands assume that you are pugged into <strong>eth0</strong> – if there is more than one NIC on the computer to be imaged it might be <strong>eth1</strong> or higher) <li>Test connection by typing at prompt <strong>ping –c 5 192.168.0.100</strong> or <strong>ping –c 5 192.168.0.101</strong> as appropriate</li></ul> <li>On on-site laptop <ul> <li>Connect collection hard disk drive <li>Launch terminal and at prompt type <strong>sudo su</strong> <li>At prompt type <strong>fdisk –l</strong> to identify storage drive <li>Create a folder to mount the storage drive to by typing <strong>mkdir /mnt/(name of your folder</strong>) <li>Next mount the storage drive to your folder by typing <strong>mount /dev/(sdb2 or whatever) /mnt/(name of your folder)</strong> <li>Now we create a netcat listener and a pipe to ewfacquirestream – at prompt type but donʼt press enter just yet<strong> nc –l 1234 | ewfacquirestream –c none –b 4096 –C case_number –D description –w –E evidence_number –e ʻRichard Drinkwaterʼ –t /mnt/(name of your folder)/(name of your evidence files)<br></strong>[relevant switches –c compression type: none, fast or best; -b amount of sectors to read at once: 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384 or 32768; words in italics change to suit and use single quote marks (ʻ-- --ʼ) to group more than one word]</li></ul> <li>On machine to be imaged <ul> <li>At prompt type <strong>sudo su</strong> <li>At prompt type <strong>fdisk –l</strong> to identify drive to be imaged <li>Next we prepare to <strong>dd</strong> drive to be imaged and pipe to <strong>netcat</strong> – at prompt type <strong>dd if=/dev/sdb conv=noerror,sync bs=4096 | nc 192.168.0.100 1234</strong> but donʼt press enter (if you are imaging a server with an HP Raid card the command might look something like <strong>dd if=/dev/cciss/c0d0 bs=4096 conv=noerror,sync | nc 192.168.0.100 1234</strong>)</li></ul> <li>Start imaging process by <ul> <li>Press <strong>enter</strong> within terminal on onsite laptop first to start <strong>netcat</strong> listener <li>Then press <strong>enter</strong> within terminal on machine to be imaged to start <strong>dd</strong></li></ul> <li>When the acquisition completes <strong>ewfacquirestream</strong> outputs a <em>MD5 hash calculated over data</em> value to the terminal. Either photograph this value or copy and paste it to a text file on your collection hard disk drive.</li></ol> <blockquote> <p> </p></blockquote> <h3></h3> <h3>Notes re imaging speed</h3> <p>In testing where the NICs are both gigabit speeds of over 40 Mb/s (144 GB/h) can be achieved. With 10/100 NICs up to 11 Mb/s (39.6 GB/h) can be expected. Compression and block size does affect imaging speed and if you have time it may be worth fine-tuning these settings. The settings shown in this post are probably a good starting point. To fine-tune, run the imaging process with the settings in this post. After 5 minutes or so if you are getting poor speeds stop the process and try adjusting the compression size on the onsite laptop (i.e. change from none to fast). Sometimes either doubling or halving the block size on both source and receiver machines can make a difference also.</p> DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com4tag:blogger.com,1999:blog-5057815281194312844.post-40503417085291912772012-02-08T14:05:00.001+00:002012-02-08T14:05:11.710+00:00Adobe Bridge CS3 and some MySQL stuff<p>Like buses – you wait all day for one and then two come along at once! <p>A recent case involved a number of images found within a file entitled <em>FileSystem_Nodes.MYD</em> on an Apple Snow Leopard box<em>. </em>The indictment referred to each image by its File Offset and the date of the offence was particularised with an arbitrary date relating to the date of seizure. The forensic investigator had not presented any further evidence relating directly to the images. The path to <em>FileSystem_Nodes.MYD </em>was<em> </em><pre class="csharpcode"><em>~\Library\Caches\Adobe\Bridge CS3\Cache\data\BridgeStore\FileSystem_Nodes.MYD</em></pre><pre class="csharpcode"><font face="Verdana">and within the same folder were two other files of note <em>FileSystem_Nodes.MYI</em> and <em>FileSystem_Nodes.frm. </em>As the path suggests these files are utilised by the Adobe Bridge CS3 program (later versions work differently). Those readers who are familiar with MySQL databases will recognise that the .MYD, .MYI and .frm files are constituent parts of a MYISAM table within a MYSQL database. MYD – my data, MYI – my index and the .frm is the definition of the table.</font></pre><pre class="csharpcode"><font face="Verdana">Adobe Bridge CS3 stores thumbnail and preview images as Binary Large Objects (BLOBS) within a MySQL database. These images can be seen in Figure 1 where the highlighted picture of a giraffe in the filmstrip at the bottom of the screenshot is a thumbnail picture. The larger representation of the same picture in the centre of the screenshot is a preview picture.</font></pre><pre class="csharpcode"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_pYmN9rwcQ20b-OmQBA1KIjmH-vDYKUV_rHqaaHdyWvjg7wGqEN2hpfXC26ZgB1jOpSncjJ1fjYzEwPMIGkCkFiJbjCtjogzgU6YVKnJoCxHFNs_P1KUtMERGGJypbN_56lMlSHZ3Q9J2/s1600-h/image%25255B3%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvhyHAWP7sgUnyEXJ9sy_nztzW5w8WvJF48wNDrOhC5m6RiX2-vE6xPcEZza1lscF7JLwG-jMtSFh18m94dEcakenFcy9ffjap_P8U2PLkZlJOKYqeCNnIh30oLtUpWjdHOCKO1BBcjaDj/?imgmax=800" width="455" height="348"></a></pre><pre class="csharpcode"><strong>Figure 1</strong></pre><pre class="csharpcode"><font face="Verdana">I was tasked with ascertaining more information about each picture located within the <em>FileSystem_Nodes.MYD</em> file. So in order to do this </font></pre><br /><ul><br /><li><pre class="csharpcode"><font face="Verdana">I installed MySQL version 5.5.20 on a test Apple iMac running Snow Leopard (I would expect that a MS Windows version would work just as well). </font></pre><br /><li><pre class="csharpcode"><font face="Verdana">Once installed I made sure that the MySQL database server was not running (which if you have installed the Mac version of MySQL is easy to do because an option to toggle on or off is added to the Macs system preferences – on a Windows box I would probably install MySQL administrator and use that program to turn the db server on or off). </font></pre><br /><li><pre class="csharpcode"><font face="Verdana">Then I copied the <em>BridgeStore </em>folder into the default location for MySQL databases which was at the path </font><font face="Verdana"><em>Macintosh HD\usr\local\mysql-5.5.20-osx10.6-x86\data</em> on my Mac and restarted the MySQL database server.</font></pre><br /><li><pre class="csharpcode"><font face="Verdana">Using MySQL Administrator I could view some information relating to the <em>BridgeStore</em> database</font></pre></li></ul><br /><style type="text/css">.csharpcode, .csharpcode pre<br />{<br /> font-size: small;<br /> color: black;<br /> font-family: consolas, "Courier New", courier, monospace;<br /> background-color: #ffffff;<br /> /*white-space: pre;*/<br />}<br />.csharpcode pre { margin: 0em; }<br />.csharpcode .rem { color: #008000; }<br />.csharpcode .kwrd { color: #0000ff; }<br />.csharpcode .str { color: #006080; }<br />.csharpcode .op { color: #0000c0; }<br />.csharpcode .preproc { color: #cc6633; }<br />.csharpcode .asp { background-color: #ffff00; }<br />.csharpcode .html { color: #800000; }<br />.csharpcode .attr { color: #ff0000; }<br />.csharpcode .alt <br />{<br /> background-color: #f4f4f4;<br /> width: 100%;<br /> margin: 0em;<br />}<br />.csharpcode .lnum { color: #606060; }<br /></style><br /><pre class="csharpcode"><font face="Verdana"></font> <a href="http://lh4.ggpht.com/-ggDy1LgpfdI/TzKA_Q54VTI/AAAAAAAABj8/CEfIvzX7kAw/s1600-h/image%25255B7%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhi9UWAspzNGcrdrznrqY1ceicshyKO8L-KeHqloVYRXtfATw38EqvzB4uF3yXHU6Pe64i7ea9RNQRCNIL6IGxvme9tzZ-3SLa4_6vZRwlF18oC0-LOORciqlMbBfSpSRHBA2_IhnMddjNX/?imgmax=800" width="511" height="141"></a></pre><pre class="csharpcode"><strong>Figure 2</strong></pre><br /><ul><br /><li><pre class="csharpcode"><font face="Verdana">We now need to query the database and also be able to view and save out the relevant BLOBS. To do this I used a utility called <a href="http://www.razorsql.com/" target="_blank">RazorSQL</a>. On the menu bar of this program there is a <em>Connections</em> option. Select this and <em>Add Connection Profile.</em> Work through the wizard, the bulk of the configuration can be seen in Figure 3</font></pre></li></ul><pre class="csharpcode"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiDa4iB5CptH_nNi_OqtP4qnNg95FNkU2V-D3swWyDp0BwNIGxzfva93FW0dxOSoHrXEdzD_e1B0H86-pVRYxo7jqvrKfFgtIWOcWmCfnN8jPzyF9siPGU8CADvvfIv-CDP79py9RQzZy3M/s1600-h/Screen%252520shot%2525202012-02-08%252520at%25252013.16.25%25255B5%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="Screen shot 2012-02-08 at 13.16.25" border="0" alt="Screen shot 2012-02-08 at 13.16.25" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1gTn8ayd_2mvNOOqehzjEObBMtED6N-9wmXcZao_96XJCYcZkB6_PWqOrS7H66U6nkOKBVxuCb6AxeIUI2GJHG0vVjqk4OFJCzmwDWlzjcnyjeGv_TlNA8iFswP0C7zk8c6Y9UPHW7Iyv/?imgmax=800" width="597" height="511"></a></pre><pre class="csharpcode"><strong>Figure 3</strong></pre><br /><ul><br /><li><pre class="csharpcode"><font face="Verdana">When you are connected you can enter queries in the top right hand pane.</font></pre><br /><li><pre class="csharpcode"><font face="Verdana">The query <strong><em>show columns from FileSystem_Nodes</em> </strong>tells us that each record within the table has 52 fields as shown in Figure 4</font></pre></li></ul><pre class="csharpcode"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLVLF2CfCJ7I9BKY8ScNc1ZT8NaDBAPXu6DWFGbUZTIglr86CcFJws0xl3lG0PuQZKMLLFTQrzuCRPZibpo7oHrmHaonuuMsogNCDh6wQb50HCKymowkXbrnwYKxV_UnwdCbr-_r_brdEe/s1600-h/Screen%252520shot%2525202012-02-08%252520at%25252013.40.20%25255B5%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="Screen shot 2012-02-08 at 13.40.20" border="0" alt="Screen shot 2012-02-08 at 13.40.20" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEFrR2VcCEj0BqAo9v0zXTlhjVj2f28EyvfxHRQ4_U-rcrsm7gmYTeqHtppIg_yHnn4zL77i3ySGL-CskkfjEWU5w2SYABn2Yv3go1hLCFyn0UfAOBIJtaHPbY7Z-b5GuKYQFin2rVbJhQ/?imgmax=800" width="590" height="783"></a></pre><pre class="csharpcode"><strong>Figure 4</strong></pre><br /><ul><br /><li><pre class="csharpcode"><font face="Verdana">The fields of particular interest are <em>displayPath</em>, <em>created</em>, <em>thumbnail</em> and <em>preview</em></font></pre><br /><li><pre class="csharpcode"><font face="Verdana">Other useful SQL queries may include <strong>Select * from FileSystem_Nodes </strong>or <strong>Select id, displayPath, created from FileSystem_Nodes</strong></font></pre><br /><li><pre class="csharpcode"><font face="Verdana">To view the thumbnail or preview blobs execute a SQL query such as one of the examples above and in the results pane scroll across to the preview or thumbnail column. Once there select a cell containing an ASCII representation of the binary blob data, right click and select <em>Binary Data Editor, </em>in the resulting window click on the <em>View Image </em>button.</font></pre></li></ul><pre class="csharpcode"><font face="Verdana">In summary it was possible to establish the original path and date created for each picture carved from the <em>FileSystem_Nodes.myd</em> file using this method.</font></pre><pre class="csharpcode"><font face="Verdana"></font> </pre><br /><h1></h1><br /><h4>References </h4><br /><style type="text/css">.csharpcode, .csharpcode pre<br />{<br /> font-size: small;<br /> color: black;<br /> font-family: consolas, "Courier New", courier, monospace;<br /> background-color: #ffffff;<br /> /*white-space: pre;*/<br />}<br />.csharpcode pre { margin: 0em; }<br />.csharpcode .rem { color: #008000; }<br />.csharpcode .kwrd { color: #0000ff; }<br />.csharpcode .str { color: #006080; }<br />.csharpcode .op { color: #0000c0; }<br />.csharpcode .preproc { color: #cc6633; }<br />.csharpcode .asp { background-color: #ffff00; }<br />.csharpcode .html { color: #800000; }<br />.csharpcode .attr { color: #ff0000; }<br />.csharpcode .alt <br />{<br /> background-color: #f4f4f4;<br /> width: 100%;<br /> margin: 0em;<br />}<br />.csharpcode .lnum { color: #606060; }<br /></style><br /><br /><p><a href="http://http://en.wikipedia.org/wiki/MyISAM" target="_blank">http://http://en.wikipedia.org/wiki/MyISAM</a></p><br /><p><a href="http://dev.mysql.com/doc/refman/5.5/en/myisam-storage-engine.html" target="_blank">http://dev.mysql.com/doc/refman/5.5/en/myisam-storage-engine.html</a></p> DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com2tag:blogger.com,1999:blog-5057815281194312844.post-63266144401641065772012-02-08T11:49:00.001+00:002012-02-08T11:49:08.487+00:00Missing in action<p>No not me (although I have been missing for some time!) I’m talking about the registry key</p><pre class="csharpcode">HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Url History\DaysToKeep</pre><br /><p>For those of us looking at dead boxes this key can be found within each users NTUSER.dat registry file and is used to record how many days history Internet Explorer keeps for the particular user. As many of us know the default is 20 days. In a recent case the value of this key was pertinent and when I went to examine it on two separate boxes I found it was missing.</p><br /><p>For the record one box was running IE8 on Windows 7, the other IE6 on XP. I also checked out a test VM of mine running IE7 on Vista for good measure and the key was missing on that box also.</p><br /><p>So after a little bit of testing I have established that this key is only created if the user visits the settings dialogue shown below in Figure 1. If the user does not visit this dialogue since the browser’s installation (or for that matter after the deletion of the registry key) the registry key is not created. Once this dialogue is visited the registry key is created whether or not the days to keep setting is actually changed.</p><br /><p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiRywp8HMP6PVCX8Eh0OZzwm1xTA49J-3-FxFpuo6lgVnrJx31nLUfkouPD7R7cQg0MnFbUipWj8pMsl-EC9_2SB5RxJ6EiC3-rDu8EksikFRXMUUFn-CuPG1bWUeM_H04NhOG2g1tRtDNh/s1600-h/HistorySettings%25255B4%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="HistorySettings" border="0" alt="HistorySettings" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtxH-wFp4ry7INLiXuQvjNtAz-DtrrFrYMhXFHMpcR93DC_iDhWLDArvmcR5Bj2xn2fGQa0nmShkw07lgZtVbXDBgUbxE5cEXU8ldLbF8WYPCZE06mf3CC7q7GfDLqG7ahg1zj1f38av30/?imgmax=800" width="237" height="305"></a> </p><br /><p><strong>Figure 1</strong></p><br /><p>It has been suggested to me that in the absence of the registry key detailed above the registry key<pre class="csharpcode">HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Url History\DaysToKeep</pre><br /><style type="text/css">.csharpcode, .csharpcode pre<br />{<br /> font-size: small;<br /> color: black;<br /> font-family: consolas, "Courier New", courier, monospace;<br /> background-color: #ffffff;<br /> /*white-space: pre;*/<br />}<br />.csharpcode pre { margin: 0em; }<br />.csharpcode .rem { color: #008000; }<br />.csharpcode .kwrd { color: #0000ff; }<br />.csharpcode .str { color: #006080; }<br />.csharpcode .op { color: #0000c0; }<br />.csharpcode .preproc { color: #cc6633; }<br />.csharpcode .asp { background-color: #ffff00; }<br />.csharpcode .html { color: #800000; }<br />.csharpcode .attr { color: #ff0000; }<br />.csharpcode .alt <br />{<br /> background-color: #f4f4f4;<br /> width: 100%;<br /> margin: 0em;<br />}<br />.csharpcode .lnum { color: #606060; }<br /></style><br />takes over (found in the SOFTWARE registry file on a dead box). In my testing this key could be edited to another value instead of the default 20 days and the days to keep listed in the settings in Figure 1 would remain at 20 days. This obviously begs the question what is this key for. As far as I can ascertain it is possible to set a group policy to enable a per machine (as opposed to a per user) setting and in that case this key takes effect.<br /><br /><p>Until next time.</p> DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-34039988159176609242011-07-02T23:10:00.003+01:002011-07-03T20:25:31.812+01:00SQLite overflow pages and other loose ends...<div style="clear: both;">This is the fourth post dealing with the elements making up SQLite databases and complements the previous three:</div><ul style="clear: both;"><li><a href="http://forensicsfromthesausagefactory.blogspot.com/2011/04/carving-sqlite-databases-from.html" target="_blank">Carving SQLite databases from unallocated clusters</a></li>
<li><a href="http://forensicsfromthesausagefactory.blogspot.com/2011/05/sqlite-pointer-maps-pages.html" target="_blank">SQLite Pointer Maps pages</a></li>
<li><a href="http://forensicsfromthesausagefactory.blogspot.com/2011/05/analysis-of-record-structure-within.html" target="_blank">An analysis of the record structure within SQLite databases</a><br />
</li>
</ul><div style="clear: both;"></div><div>We will remember from these previous posts that:<br />
<ul style="clear: both;"><li>The entire database file is divided into equally sized <em>pages - </em>SQLite database files always consist of an exact number of <em>pages</em></li>
<li>The <em>page </em>size is always a power of two between 512 (2<sup>9</sup>) and 65536 (2<sup>16</sup>) bytes<br />
</li>
<li>All multibyte integer values are read big endian</li>
<li>The <em>page</em> size for a database file is determined by the 2 byte integer located at an offset of 16 bytes from the beginning of the database file<br />
</li>
<li><em>Pages</em> are numbered beginning from 1, not 0<br />
</li>
<li>Therefore to navigate to a particular <em>page </em>when you have a <em>page</em> number you have to calculate the offset from the start of the database using the formula:<br />
<em>offset = (page number-1) x page size</em></li>
</ul></div><div>and that the database may have the following possible page types:</div><div><div><ul style="clear: both;"><li>An index B-Tree internal node</li>
<li>An index B-Tree leaf node</li>
<li>A table B-Tree internal node</li>
<li>A table B-Tree leaf node</li>
<li>An overflow page</li>
<li>A freelist page </li>
<li>A pointer map page</li>
<li>The locking page</li>
</ul></div></div><div>In this post I am going to take a closer look at Overflow pages.</div><div><br />
Overflow pages are required when a record within a database requires more space than that available within a cell in one database page. One SQLite database of forensic interest is the Cache.db file maintained by the Apple Safari web browser. One of the tables within this database is entitled <strong>cfurl_cache_blob_data </strong>which uses the <em>receiver_data </em>field to store the cached item itself (e.g. cached jpgs, gifs, pngs, html et al ) as a BLOB. A BLOB is a <strong>B</strong>inary <strong>L</strong>arge <strong>OB</strong>ject. These cached objects often require overflow pages and we can demonstrate the mechanics of them by walking through a record within Cache.db.</div><div><br />
If you run a file carver across a Cache.db file searching for pictures you are likely to carve out a number corrupt pictures as shown in the example within Figure 1.</div><div><br />
</div><div style="clear: both;"><a class="image-link" href="http://lh5.ggpht.com/-OPn2zKoVa_Y/Tg8SLJ-hcMI/AAAAAAAABUk/xj2DLWs0a-g/s800/corrupt_picture.png"><img align="left" class="linked-to-original" height="270" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjEVPUj1HyiDlNjIh3-RnHaZUpunqunwgAWqShZkklfMbJ_ZX3Zhap1bqUFcpH0wnab7wBRiIuyccx7atbfGegO0UcWv0oP2NqATKZcwdUfXrIS1VH-vNU92XnuB-63erOv8f9M1T5F4IO/s800/corrupt_picture-thumb.png" style="display: inline; float: left; margin-bottom: 10px; margin-left: 0px; margin-right: 10px; margin-top: 0px;" width="380" /></a><em>Double click to enlarge</em></div><div style="clear: both;"><strong>Figure 1</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;">It can be seen that this picture starts at File offset 4583317 within Cache.db. By examining the two bytes at offset 16 within this SQLite database we have established that the database page size is 1024 bytes. The record that contains this picture has six fields as shown in Figure 2.</div><div style="clear: both;"><br />
</div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg-Q6wb_7YGb-ErFusubCYS1MVJLpiAK27baNXXRYzCnG6qFv7uM9IS91lYCpwyNX4B27gJzR2iRlhHfs6WXWXDO7mvwjOLW6Qq-Engda-YgHqatCcBS731qeF7socTNM0qMwrnjeM6MAZf/s800/cache.db_schema.png"><img align="left" class="linked-to-original" height="127" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRhF-LFM5c5RWS2qosdq_1dsJKETZ3J8wD41RdyyRHG1rj5F1lt4Ng9m8kK24T4pxLZ5BXW6FN4wF3RfaXlNwFMPhBJeUYpBmzTfLGW3DXLvPItXLBPbRq9Pik82fRzrTmuBeE-f0YR-e7/s800/cache-thumb.db_schema.png" style="display: inline; float: left; margin: 0 10px 10px 0;" width="380" /></a><em>Double click to enlarge</em></div><div style="clear: both;"><strong>Figure 2</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;">As discussed in my earlier post <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/05/analysis-of-record-structure-within.html" target="_blank">An analysis of the record structure within SQLite databases</a> the data making up this record is store in a serialised way (the data representing field 1 is immediately followed by the data representing field 2 and so on with no delimiters). It can be seen therefore that a cell storing a record within the <strong>cfurl_cache_blob_data </strong>table is almost bound to overflow the 1024 byte database page.</div><div style="clear: both;">In our example our corrupt picture starts at FO 4583317. To calculate the database page it is stored in we divide the offset by the page size 4583317/1024=4475.8955078125 and round up to establish the page number. Our corrupt picture header is in page 4476.</div><div style="clear: both;">The SQLite.org file format states that <em>overflow pages are chained together using a singly linked list. The first 4 bytes of each overflow page is a big-endian unsigned integer value containing the page number of the next page in the list. The remaining usable database page space is available for record data. </em></div><div style="clear: both;">We know that our picture is likely to be stored in a number of overflow pages and we can establish the next page by looking at the first 4 bytes of the page that is in. Using the formula <em>offset = (page number-1) x page size </em>I can calculate that the offset of these 4 bytes at the start of the page is 4475 x 1024=4582400. This offset can be seen in Figure 3.<br />
<br />
</div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBO7tcNG7JMXvksR3CEhaF9yEO1XJCBvvJIGVUVSIYakzl1csGTAb_Cab-XwW28UpXUvQuspadIOpUv-IoUqyY5v83j5F5hL0jgR6vVJ8cNMNrMR1t59zaM36gMSUZswmAPAJj576iK3V4/s800/4_byte_overflow_pg_no.png"><img align="left" class="linked-to-original" height="274" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhRhEJBEah8t_X4gt_jPNDsd1KCPnEYOG1CrX5O-0jZfsfJoMvNf4OOvGH_HsNRtU-bJIi3a5yPL1brV3ba6Tyt9C_t86czq8O1rA34wxyYvwCJkPNjxDGP0HWbq_Qjt1igMvrKl4eVgBlC/s800/4_byte_overflow_pg_no-thumb.png" style="display: inline; float: left; margin: 0 10px 10px 0;" width="380" /></a><em>Double click to enlarge</em></div><div style="clear: both;"><strong>Figure 3</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;">The 4 bytes in hex are 00 00 11 7D which decoded big endian is 4477. The next page therefore in the linked list is page 4477. The first 4 bytes of this page found at offset 4583424 in hex are 00 00 11 7E which decoded big endian is 4478. The first 4 bytes of this page found at offset 4584448 in hex are 00 00 11 7F which decoded big endian is 4479. The first four bytes of this page found at offset 4585472 are in hex 00 00 00 00. This value signifies the last page in the linked list.</div><div style="clear: both;">I can be seen in this example that our corrupt picture starts in page 4476 and overflows into pages 4477, 4478 and 4479. Obviously the overflow pages are contiguous in this case, so in theory at least, if I copy the data from the jpg header of the corrupt picture to the jpg footer and edit out the 'corruption' I should end up with a complete picture. The corruption was likely caused by the overflow page values at the start of each page so using a hex editor I can remove these and <em>hey presto:<br />
</em><br />
<em><br />
</em></div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjWIdemvJISBSIXXDpsG1kVr6gkZ1XKyUJXcUUeM3aW_lRIXbUARLWyRW6PamtZ96VZtJybSJTzAtnn2BfJ-8i2GTzgBPKLRJSUKrunWp1CwDvanJuPLI7RUIz8IotvbIATdUns07Zrhm8b/s800/corrupt.jpg"><img align="left" class="linked-to-original" height="110" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqU2g3DvXVvLEgtcwwZfY8GCZbuzsAlegF_w2sGPuBxRYIBmskLS9koianrTEavAwBwpe4UnLS2xiGDNnoXRIOUMOqhF6H0XF2Z4Pp7e6LKQ_CEnwxp5tMqlIM0bHbmicbK5RixhhVYQW8/s800/corrupt-thumb.jpg" style="display: inline; float: left; margin: 0 10px 10px 0;" width="110" /></a><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Essentially what we have done here is start in the middle of the record and work forwards to the end. Because overflow pages are chained together using a linked list this is relatively straightforward. </div><div style="clear: both;">But what do we do if we want to locate the earlier pages in the record? This is a little more complicated because each overflow page does not contain the page number of the previous page. The Safari cache.db SQLite 3 database is an auto-vacuum database so we could utilise Pointer Map pages to locate the parent page of the page (4476) where our corrupt picture header is stored. You will recall from my previous post that Pointer Map pages store a 5 byte record relating to every page that <strong>follows</strong> the Pointer Map <em>page. </em>Pointer Map pages found in Safari Cache.db files will have a lot of entries that relate to overflow pages. The 5 byte records are structured with 1 byte indicating a Page Type and then 4 bytes, decoded big endian, referencing the parent page number as follows:</div><div style="clear: both;"></div><ul style="clear: both;"><li><strong>0x01</strong> 0x00 0x00 0x00 0x00<br />
This record relates to a B-tree root page which obviously does not have a parent page, hence the page number being indicated as zero.</li>
<li><strong>0x02</strong> 0x00 0x00 0x00 0x00<br />
This record relates to a free page, which also does not have a parent page.</li>
<li><strong>0x03 </strong>0xVV 0xVV 0xVV 0xVV (where VV indicates a variable)<br />
This record relates to the first page in an overflow chain. The parent page number is the number of the B-Tree page containing the B-Tree cell to which the overflow chain belongs.</li>
<li><strong>0x04 </strong>0xVV 0xVV 0xVV 0xVV (where VV indicates a variable)<br />
This record relates to a page that is part of an overflow chain, but not the first page in that chain. The parent page number is the number of the previous page in the overflow chain linked-list.</li>
<li><strong>0x05 </strong>0xVV 0xVV 0xVV 0xVV (where VV indicates a variable)<br />
This record relates to a page that is part of a table or index B-Tree structure, and is not an overflow page or root page. The parent page number is the number of the page containing the parent tree node in the B-Tree structure.<br />
</li>
</ul>We can expect to see a lot of Page Types 0x03 and 0x04. So how do we find the pointer map page? We know that the Pointer Map page may contain up to (database page size/5) records (rounded down if necessary) - in this case 1024/5=204.8 so there are 204 records in each Pointer Map page. The first Pointer Map page is Page 2. This is followed by 204 pages and then another Pointer Map page, page 207, followed by 204 pages and then another Pointer Map page, page 412 and so on. In other words there is a Pointer Map page every 205th page, starting page 2. In our example we know that our corrupt picture header is in database page 4476 and the applicable Pointer Map page is prior to it. To calculate the applicable Pointer Map page number we divide 4476 by 205 = 21.834146341463415, round down to 21 and multiply by 205 and then add 2 which equals 4307. The applicable Pointer Map page for page 4476 of the database is page 4307. Using the formula <em>offset = (page number-1) x page size </em>I can calculate that the offset to this page is 4409344. This page can be seen in Figure 4. Each Page Type flag where it references an Overflow page is bookmarked in green, other Page Types are in blue. The first 5 byte record relates to database page 4308, the second 5 byte record page 4309 and so on. The record for page 4476 is the 169th record on the Pointer Map page (4476-4307).<br />
<br />
<div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgotGQonqIiDGg1dWc6p3Q6oCCVp_vXu1eO1lxZHAElfEd7i511Y0fFS_JwbYLOppzWiSDjvWZl7BNlCLsML3n9hLw8egi677aPFUKSrbk55ExzqHmF94qXkPEgEmUBGeR9z5Bq5sP6Ml-G/s800/pointer_map_at_page_1.png"><img align="left" class="linked-to-original" height="570" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVCpEjD4C1ijAJSvqSzoAS2Ltb8ZNyfDKwNg4Li8b9pu-w2dFPLb_gk3B39PPrfgmYGSYKorlGiexpCRaAO77_8tu1bhaSdhsDt_Xi-NOtAgbjmgPI_XM42gAlm0DSqYTqTRQtUZKX7oot/s800/pointer_map_at_page_1-thumb.png" style="display: inline; float: left; margin: 0 10px 10px 0;" width="286" /></a><em>Double click to enlarge</em></div><div style="clear: both;"><strong>Figure 4</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;">It can be seen that the 169th record is in hex <strong>04 00 00 11 7B</strong>. This record has a flag 0x04 which indicates that this record relates to a page that is part of an overflow chain, but not the first page in that chain. The parent page number is 00 00 11 7B decoded big endian to page 4475. The record for page 4475 is the 168th record on the page <strong>04 00 00 11 7A. </strong>This record also<strong> </strong>indicates that the page is part of an overflow chain but not the first page. The parent page number is 00 00 11 7A decoded big endian to page 4474. The record for page 4474 is the 167th record on the page <strong>03 00 00 11 6E. </strong>This record has a flag 0x03 which indicates that this record relates to the first page in an overflow chain. The parent page number is the number of the B-Tree page containing the B-Tree cell to which the overflow chain belongs. The parent page number is 00 00 11 6E decoded big endian to page 4462.</div><div style="clear: both;">Using the formula <em>offset = (page number-1) x page size </em>I can calculate that the offset to the beginning of this page is 4568064. We can now decode the page header (detailed more fully in the post <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/05/analysis-of-record-structure-within.html" target="_blank">An analysis of the record structure within SQLite databases</a> ) shown in Figure 5.<br />
<br />
</div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8TvhzSbLeTV9dmDFUhetWp1lH6uotq43CRQuGGn3L8xf0A9Y2jbG0xRKf9x8oRg_QTdfrN1I7LLPmbt30sx45Cf9A4OJNIrkcztmGwqr7GPpSmokVA4SorXNEodc2nZCl7HKA58KQ2j0L/s800/Page_header_and_cell_pointer_array_page_no_4462.png"><img align="left" class="linked-to-original" height="92" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjU7YphpAVOkQyG18XR7IsQtnKW9dDwwyZnpYi4N3iq1lG8D5Pi7ng8-O2CkXUOhs5h62M98fNAzkbfrxua4sCWI_CbM7ojABoqMyQ7TMLBc8iEYDJni6KjOr2qqiGU6fm33PZrsucZrs2/s800/Page_header_and_cell_pointer_array_page_no_4462-thumb.png" style="display: inline; float: left; margin: 0 10px 10px 0;" width="380" /></a><em>Double click to enlarge<br />
</em></div><div style="clear: both;"><strong>Figure 5</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;">Figure 5 shows the page header of the B-tree leaf node page. The first byte <strong>0D</strong> is a flag indicating the page is a table B-tree leaf node. The next two bytes <strong>00 00 </strong>indicate that there are no free blocks within the page. The next two bytes <strong>00 03</strong> read big endian indicate that there are three cells stored on the page. The next two bytes at offset 5 within the page header <strong>00 EB </strong>decoded big endian give a value of 235 which is the byte offset of the first byte of the cell content area relative to the start of the page. The last byte of the eight byte page header <strong>00 </strong>is used to indicate the number of fragmented free bytes on the page, in this case there are none. The remaining highlighted three pairs of bytes <strong>02 60</strong>, <strong>01 F1</strong> and <strong>00 EB </strong>are the cell pointer array for this page. These three values are offsets to the start of each cell when decoded big endian are 608, 497 and 235 respectively. We will focus on the cell at offset 235. At offset 235 we find two Varints representing the <em>Length of Payload</em> and <em>Row ID</em> (see Figure 6).<br />
<br />
</div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8ZDhM5sp4jxRW_hvqECyZhYsYRhX-YB-B6wqVy1l5P3PtqWB9gpVmATxH0tD_X_t_GpBuCsKXzj5NO3Jzwm5j4EaSln7EzsGVs2uSwxCKS9n4p8RHMBi6Q7aTLS-fzjzmBrYvKyFVZ2A9/s800/offset_235_in_encase.png"><img align="left" class="linked-to-original" height="354" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhSRhbcXfz8QXLHw4NdP4u9o5v_epfB_GgVW5b61ZNC_UumAzgxenss2jSKLLyBorALfDwCuZA28pAG1TED4ashK_MuIw8IbKxv1ZVY6AWw5UUxzwy2fUzSleOwre-5TO0V8xvQfYDGQxqt/s800/offset_235_in_encase-thumb.png" style="display: inline; float: left; margin: 0 10px 10px 0;" width="380" /></a><em>Double click to enlarge</em></div><div style="clear: both;"><strong>Figure 6</strong></div><div style="clear: both;"><br />
The varints are<strong> B1 66</strong> and <strong>82 11</strong>. The calculation needed to decode them follows in Figure 7:<br />
<br />
</div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6QPFUK6XWsSVRc9_AY3bdBPCTrN3g3L6RaRwr8NFdgnn7BojXdMbag4na1VTdg1zQ2VNQ1JXbth-T-j18rVcrBtk-PvqOtez8po_zFiBmCnAcFdZ-IGeimh-jErjzeWbZTKSnWmRngmv2/s800/Screen_shot_2011-07-02_at_21.21.43.png"><img align="left" class="linked-to-original" height="341" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGyrL2tLwRsWG7oJ5BAcyWq2t4hyphenhyphennmkNmvhx0nvB4BRU89npu1obsidURV4RkLGMPIkwLKFYwe24RhLsLMomN4aZ6MZPdgZYsZJylNurGVcOOoroo-myIM8MFOcBxtILQ_o_GNrF0WQEZA/s800/Screen_shot_2011-07-02_at_21-thumb.21.43.png" style="display: inline; float: left; margin: 0 10px 10px 0;" width="380" /></a><em>Double click to enlarge<br />
</em></div><div style="clear: both;"><strong>Figure 7</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;">Following the <em>Length of Payload</em> and <em>Row ID </em>are varints representing <em>the Length of the Payload Header </em>and<em> </em>the serial type codes of the <em>entry_ID, response_object, request_object, receiver_data, proto_props </em>and <em>user_info </em>fields respectively as shown in Figure 8:<br />
<br />
</div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-LlxcWcIycjy4Ke7IA65EFFKcxOhNeWqId7X3x2vm9eAswhbbKxCzG4SHeFCJaCLMZ6Bjalz-yIhipc9ORBSnNy1WnENWFgWqrySJNiSDKEK_TZFzhgFyojyb0n4q4ZlN6-BDgRoFcsVG/s800/payload_header.png"><img align="left" class="linked-to-original" height="166" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiF6PQvfwk8oyu21cX6WxX0DCYsD4qrF7_ehAdUvwvhX6flfDuJmYOH9Iw3VnfeEr2EzNWYR_LbXSIERUse-8nsg7mkvWqfPckz9C6ISup8BQW6vjq0uVAMtVhZGzzDHgH02C06fLUNtIxB/s800/payload_header-thumb.png" style="display: inline; float: left; margin: 0 10px 10px 0;" width="380" /></a><em>Double click to enlarge</em></div><div style="clear: both;"><strong>Figure 8</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;"></div><div style="clear: both;">Figure 8 shows highlighted in blue and green the first three elements of the Cell make up - the <em>Payload Length</em>, the <em>Row ID</em> and the <em>Payload Header. </em>We have already decoded the <em>Payload Length</em> <strong>B1 66</strong> and the <em>Row ID</em> <strong>82 11</strong>. The next byte <strong>h0A </strong>denotes the length of the <em>Payload Header </em>which is in this case 10 bytes (including the <em>Payload Header Length</em> byte). It can be seen therefore that the remaining 9 bytes contain the <em>varints <strong>00, 9B 54, 96 3E, B1 4A, 00 </strong>and <strong>00</strong></em>. To determine what each <em>varint</em> indicates we have to consult the Serial Type Code chart detailed in the post <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/05/analysis-of-record-structure-within.html" target="_blank">An analysis of the record structure within SQLite databases</a> . Each Serial Type Code details the type and length of the data in the <em>payload</em> that follows the <em>payload header</em>. </div><div style="clear: both;"></div><ul style="clear: both;"><li><strong>00 </strong>This serial type code indicates that the first field is NULL and the content length is 0 bytes. We know that the first field in our record relates to Row ID however the SQLite.org file format states <em>If a database table column is declared as an INTEGER PRIMARY KEY, then it is an alias for the rowid field, which is stored as the table B-Tree key value. Instead of duplicating the integer value in the associated record, the record field associated with the INTEGER PRIMARY KEY column is always set to an SQL NULL.</em><br />
</li>
<li><strong>9B 54 </strong>This serial type code has a value of 3540 which is greater than 12 and an even number. The chart indicates therefore that this field is a BLOB (3540-12)/2 bytes in length [1764 bytes]<br />
</li>
<li><strong>96 3E </strong>This serial type code has a value of 2878 which is greater than 12 and an even number. The chart indicates therefore that this field is a BLOB (2878-12)/2 bytes in length [1433 bytes]<br />
</li>
<li><strong>B1 4A </strong>This serial type code has a value of 6346 which is greater than 12 and an even number. The chart indicates therefore that this field is a BLOB (6346-12)/2 bytes in length [3167 bytes]<br />
</li>
<li><strong>00 </strong>This serial type code indicates that the field is NULL<br />
</li>
<li><strong>00 </strong>This serial type code indicates that the field is NULL</li>
</ul><div style="clear: both;">The serial type code for the <em>response_object </em>indicates that this field is a BLOB 1764 bytes in length. The entire database page would not be big enough to store this BLOB and the cell is even less capable. Figure 9 shows each cell highlighted alternately blue and green:<br />
<br />
</div><div style="clear: both;"><a class="image-link" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjx2JfP2FHxbd91Kn6wHpgQC6_1P8JnpJxJPL5EZK8qEgMA4kY9ri3NkxYpOh8T7laaFLKjRt2HYN13Xh3CjGJRHDVEt27ZBDH1yyoh8m1ksJK43beUNgvFX4T6-j8_JeKA-pjw6Ow9bbHK/s800/3_cells_highlighted.png" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img align="left" class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhI0nmtFy2fbWDuqyaQi-NOy4JMBTNWPs_BOBIn_2TzlkDzLrYdA2Whb4DXAgW7PP2W7Pu0v4Zli8jTjKelXwQM4NC9eGO1jlS3YlNCBJxLDrUMm1n3Vr-PQX0e2BvyWRN0H6lj-5nEpGLa/s1600/3_cells_highlighted-thumb.png" style="display: inline; float: left; margin-bottom: 10px; margin-left: 0px; margin-right: 10px; margin-top: 0px;" /></a><em>Double click to enlarge<br />
</em></div><div style="clear: both;"><strong>Figure 9</strong></div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;">The first blue shaded area is the cell the elements of which are duscussed above. The last four bytes of this cell highlighted in darker blue is the hex value <strong>00 00 11 7A </strong>which when decoded big endian gives the value 4474. This is the page number of the first Overflow page for this cell and is consistent with the information found in the Pointer Map page discussed above.<br />
<br />
</div><div style="clear: both;"><strong>Next Post</strong></div><div style="clear: both;">Following on from my earlier SQLite blog posts James Crabtree has been kind enough to code a Varint decoder and Alex Caithness of CCL has supplied me with his fully featured SQLite record recovery tool EPILOG. I'll review this software next time. Thanks to James and CCL.</div><div style="clear: both;"><strong><br />
</strong></div><div style="clear: both;"><strong>References</strong><br />
http://www.sqlite.org/fileformat.html<br />
http://www.sqlite.org/fileformat2.html</div><br class="final-break" style="clear: both;" />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-90549419869030543062011-05-10T18:11:00.001+01:002011-05-10T20:44:04.593+01:00An analysis of the record structure within SQLite databases<div style="clear: both;">My two previous posts <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/04/carving-sqlite-databases-from.html">Carving SQLite databases from unallocated clusters</a> and <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/05/sqlite-pointer-maps-pages.html">SQLite Pointer Maps pages</a> looked at the structure of SQLite databases as a whole. Information contained in those posts may hopefully facilitate the carving of complete SQLite databases. This post is aimed at examining the potential of carving individual records within an SQLite database but should be read in conjunction with the Carving SQLite databases from unallocated clusters post.</div><div style="clear: both;"><br />
</div><div style="clear: both;"><strong>Background</strong><br />
Carving individual SQLite database records in certain circumstances may be more fruitful than carving whole databases. There are in fact a number of applications that do exactly this for some types of SQLite database. For example <a href="http://ff3hr.sourceforge.net/">Firefox 3 History Recovery</a> (FF3HR) is an application written to recover Firefox records. A paper entitled <em>Forensic analysis of the Firefox 3 Internet history and recovery of deleted SQLite records </em>written by <em>Murilo Tito Pereira </em>also deals with the recovery of Firefox records.</div><div style="clear: both;">SQLite databases can be considered as a mini file system in their own right. Within this file system are areas that are marked as free that may contain deleted data. Record based recovery may help identify records that have been deleted but are still contained within the parent SQLite database. More obviously record based recovery is indicated where only deleted and partially overwritten databases are available. However for record based recovery to be useful the data you wish to recover must be stored within one table within the SQLite database concerned. If it is necessary to query two or more tables to extract useful data record based recovery is probably not going to be appropriate.<br />
<br />
</div><div style="clear: both;"><strong>Table Record</strong><br />
<br />
</div><div style="clear: both;"><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicyll9FanvnazSxQMjiGBDjKVCa9VOIB3u2oTiY8MQUHQZmXYZ5ofnumkjtMV4WlEXc891UE2F9wdMTegRkkDrzdensTqkeDUs6OGyWjZRQmhjcU9-O_HWgrNzlKRvsf4TWzdI3MUPMywr/s1600/Chrome+URLs+table+record.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="193" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEicyll9FanvnazSxQMjiGBDjKVCa9VOIB3u2oTiY8MQUHQZmXYZ5ofnumkjtMV4WlEXc891UE2F9wdMTegRkkDrzdensTqkeDUs6OGyWjZRQmhjcU9-O_HWgrNzlKRvsf4TWzdI3MUPMywr/s400/Chrome+URLs+table+record.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><b><span class="Apple-style-span" style="font-size: small;">Figure 1</span></b></td></tr>
</tbody></table><b><i></i></b><br />
<b><i> </i></b></div><div style="clear: both;"><br />
Figure 1 shows, as viewed with the <em>SQLite Database Browser</em> software, a record within the Google Chrome History file URL table at row ID 608. This record is stored within the Google Chrome History SQLite database within a B-tree table leaf node in an area known as a cell. It can be seen from the column headers that this record consists of an <em>id</em>, a <em>url</em>, a <em>title</em>, a <em>visit_count</em>, a <em>typed_count</em>, a <em>last_visit_time</em>, a <em>hidden</em> flag and lastly a <em>favicon _id</em>. To aid viewing I will repeat the record data below:</div><ul style="clear: both;"><li><strong>ID</strong><br />
608<br />
</li>
<li><strong>URL</strong><br />
http://www.sqlite.org/fileformat2.html<br />
</li>
<li><strong>title</strong><br />
File Format For SQLite Databases<br />
</li>
<li><strong>visit_count</strong><br />
1<br />
</li>
<li><strong>typed_count</strong><br />
0<br />
</li>
<li><strong>last_visit_time</strong><br />
12949409092779476</li>
<li><strong>hidden</strong><br />
0<br />
</li>
<li><strong>favicon_id</strong><br />
46<br />
<div class="separator" style="clear: both; text-align: center;"></div><br />
</li>
</ul><div style="clear: both;">The <b>urls </b>table is stored within one table B-tree which will consist of a root page and possibly a number of internal and leaf node pages. I have established that the data representing the record detailed above is stored in a cell that exists within a B-tree table leaf node database page.</div><div style="clear: both;"><br />
</div><div style="clear: both;"><b>Cells</b></div><div style="clear: both;"><div class="separator" style="clear: both; text-align: center;"></div>Lets recap some of the information dealt with in the earlier post <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/04/carving-sqlite-databases-from.html">Carving SQLite databases from unallocated clusters</a>. SQLite databases are divided into equal sized pages, the size of which is detailed in two bytes, decoded as a 16 bit integer big endian, at offset 16 of the database file within the database header. Most of an SQLite database consists of B-tree structures consisting of one or more B-tree pages. Each B-tree page has either an 8 or 12 byte page header (depending on whether it is a leaf or internal node).<br />
<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL8VoKbUvdSGzdaL9cfmqaCiWtnwEjVA5RnFIYh7xZMeR5U6acETiL1W2QRJTExasqBipPTy0IDz2je4WryyomuvbBIGDcCqtCTXsityvERyCJUQU-FOPA4NS3DZvHi5m0wqPwGt-YUqc0/s1600/Database+graphic.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL8VoKbUvdSGzdaL9cfmqaCiWtnwEjVA5RnFIYh7xZMeR5U6acETiL1W2QRJTExasqBipPTy0IDz2je4WryyomuvbBIGDcCqtCTXsityvERyCJUQU-FOPA4NS3DZvHi5m0wqPwGt-YUqc0/s640/Database+graphic.png" width="584" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><b><span class="Apple-style-span" style="font-size: small;"> Figure 2</span></b></td></tr>
</tbody></table><br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<div style="text-align: left;"></div><div style="clear: both;">As can be seen in Figure 2 the cells tend to be at the end of each database page in an area referred to as the <i>cell content area</i>. These cells are used to store the database records, one record per cell. The first cell to be written in a database page is stored at the end of the page and additional cells work back towards the start of the page.</div></div><div style="clear: both;"><br />
</div><div style="clear: both;">The number of cells and their location within a database page is stored within the B-Tree page header at the following offsets.</div><ul><li><b>Offset 1 2 bytes 16 bit integer read big endian</b> </li>
<li>Byte offset of first block of free space on this page (0 if no free blocks)</li>
</ul><ul><li><b>Offset 3 2 bytes 16 bit integer read big endian</b></li>
<li>Number of entries (cells) on the page</li>
</ul><ul><li><b>Offset 5 2 bytes 16 bit integer read big endian</b></li>
<li>Byte offset of the first byte of the cell content area relative to the start of the page. If this value is zero, then it should be interpreted as 65536</li>
</ul><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj41weifC-ODCdP0PmbKvMwFo-_PW2TUJiRFskteltYCWlBHT2Zt2Dfw7Fn4XfZwpsPkRdA6RuOAIh6HP1YhcPszuAa8FO8yhZotGz2dbzYbZF7qPsl-whcWe3eDI6Y17fXlECMp3sMYVea/s1600/page+header+and+cell+pointers.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj41weifC-ODCdP0PmbKvMwFo-_PW2TUJiRFskteltYCWlBHT2Zt2Dfw7Fn4XfZwpsPkRdA6RuOAIh6HP1YhcPszuAa8FO8yhZotGz2dbzYbZF7qPsl-whcWe3eDI6Y17fXlECMp3sMYVea/s1600/page+header+and+cell+pointers.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><b><span class="Apple-style-span" style="font-size: small;">Figure 3 Page Header and Cell Pointer array</span></b></td></tr>
</tbody></table><div><br />
<div style="clear: both;">Figure 3 shows the page header of the B-tree leaf node page that contains the record detailed in Figure 1 above. The first byte <b>0D</b> is a flag indicating the page is a table B-tree leaf node. The next two bytes <b>00 00 </b>indicate that there are no free blocks within the page. The next two bytes <b>00 03</b> read big endian indicate that there are three cells stored on the page. The next two bytes at offset 5 within the page header <b>0B 8E </b>decoded big endian give a value of 2958 which is the byte offset of the first byte of the cell content area relative to the start of the page. The last byte of the eight byte page header <b>00 </b>is used to indicate the number of fragmented free bytes on the page, in this case there are none.</div><div style="clear: both;"><br />
</div><div style="clear: both;">The remaining highlighted three pairs of bytes <b>0C 44</b>, <b>0B EC</b> and <b>0B 8E </b>are the cell pointer array for this page. The SQLite.org file format notes helpfully state that <i>the cell pointer array of a b-tree page immediately follows the b-tree page header. Let K be the number of cells on the b-tree. The cell pointer array consists of K 2-byte integer offsets to the cell contents. The cell pointers are arranged in key order with left-most cell (the cell with the smallest key) first and the right-most cell (the cell with the largest key) last</i>. The <i>key</i> value referred to is the row ID. In this case we have three cells and therefore three offsets which when decoded big endian are 3140, 3052 and 2958. These offsets allow us to find the start of each cell, it is worth pointing out that there may be free blocks or fragments between each cell so we can not use the offsets to determine the length of each cell.</div><div style="clear: both;"><br />
</div><div style="clear: both;">The record detailed in Figure 1 is contained within the cell at offset 2958 within the page. We will decode the contents of this cell but first we better look at the make up of a cell.</div><div style="clear: both;"><br />
</div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkiYicUNBZhoGW-mtZOtx882uSo82s0CL5EprZhX4IJ8i2YeYTkyDu3BGbAbMiEsLQ4qHnScGo5-JnSI7sr6N7j-m-abBNM1onO8uzEcd9aCPuT00drk4eqhtjORG2oHTiRN4-c0SuB4ww/s1600/Cell+make+up.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="56" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkiYicUNBZhoGW-mtZOtx882uSo82s0CL5EprZhX4IJ8i2YeYTkyDu3BGbAbMiEsLQ4qHnScGo5-JnSI7sr6N7j-m-abBNM1onO8uzEcd9aCPuT00drk4eqhtjORG2oHTiRN4-c0SuB4ww/s400/Cell+make+up.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><b><span class="Apple-style-span" style="font-size: small;">Figure 4 Cell make up</span></b></td></tr>
</tbody></table><div style="clear: both;">Figure 4 indicates four areas of interest. The <i>payload </i>is the data forming the record as detailed in this example in Figure 1 and as suggested in the diagram it is stored in a serialized way with all the relevant data concatenated together. The <i>payload header </i>details how we can identify each field within the concatenated data (<i>see the Payload Header section below for details of how this works</i>). The Row ID number and the <i>Payload </i>length are stored using <i>variable length integers </i>known as <i>varints. </i>To successfully decode the Cell and Payload headers we have to be able to decode a <i>varint.</i><br />
<i><br />
</i><br />
<b>Varint</b><br />
<a href="http://www.sqlite.org/fileformat2.html">http://www.sqlite.org/fileformat2.html</a> and <a href="http://www.sqlite.org/fileformat.html#varint_format">http://www.sqlite.org/fileformat.html#varint_format</a> provides some detail in respect to how <i>varints</i> are structured. I will try here to simplify things and provide a few example decodings when we decode the cell relating to the record detailed at figure 1.<br />
<br />
<ul><li><i>Varints</i> are variable length integers between 1 and 9 bytes in length depending on the value stored</li>
<li>They are a static Huffman encoding of 64-bit twos-complement integers that uses less space for small positive values</li>
<li>Where the most significant bit of byte 1 is set this indicates that byte 2 is required, where the most significant bit of byte 2 is set this indicates that byte 3 is required, and so on</li>
<li><i>Varints</i> are big-endian: bits taken from the earlier byte of the <i>varint</i> are the more significant than bits taken from the later bytes</li>
<li>Seven bits are used from each of the first eight bytes present, and, if present, all eight from the final ninth byte</li>
</ul></div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBsDi_EWTxIWYLPJYxBVOpUghMR1fz8rDrPmZCXzBgdhxwRxKxcl-s_MCnpeVZf19Wzihw-pkY8VoAsm0Cq8qjRkvtf7eKmSVOlDq0-4OEYEuWsbjyzZbY4wuYuoOZw-swXdMS8zh2OazI/s1600/Cell+header+in+Encase.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="185" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBsDi_EWTxIWYLPJYxBVOpUghMR1fz8rDrPmZCXzBgdhxwRxKxcl-s_MCnpeVZf19Wzihw-pkY8VoAsm0Cq8qjRkvtf7eKmSVOlDq0-4OEYEuWsbjyzZbY4wuYuoOZw-swXdMS8zh2OazI/s640/Cell+header+in+Encase.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><b><span class="Apple-style-span" style="font-size: small;">Figure 5</span></b></td></tr>
</tbody></table><div style="clear: both;">Figure 5 shows the beginning of the cell at offset 2958 within the page. As shown in figure 4 the first value is the payload length represented by a <i>varint</i>. The first byte is <b>5B</b>. We have to establish the value of the most significant bit and this can be done by converting the hex 5B to binary:</div><div style="clear: both;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKOHKMYroI0Xu4uJTsrXEl9JxT-pTkQJCNUEmwPRq7B16suaV2fSmbE5hbMX4RGEiOdsXJ1KAeL8chUky71AoepMu90WqIXToDn8e7cCTFADlyQgJ2ri8Rs13JhSmWnckSH7geCkzsF1EO/s1600/hex+5B+to+binary.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKOHKMYroI0Xu4uJTsrXEl9JxT-pTkQJCNUEmwPRq7B16suaV2fSmbE5hbMX4RGEiOdsXJ1KAeL8chUky71AoepMu90WqIXToDn8e7cCTFADlyQgJ2ri8Rs13JhSmWnckSH7geCkzsF1EO/s1600/hex+5B+to+binary.png" /></a></div><div style="clear: both;">It can be seen that in this case the most significant bit is zero and therefore not set. This <i>varint</i> is only one byte long and indicates that the payload length is 91 bytes. The payload length is the length in bytes of both the payload header and the payload.</div><div style="clear: both;"><br />
</div><div style="clear: both;">The next byte is <b> 84</b>. Converting this to binary:</div><div style="clear: both;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfHFF9GESv2eTbxkEkga6vpVE0m_S_HiEOMrZJX8A2pEgWWi6Of64h7HbteMDS946ov6FfmHRJTV7ve5g2McM-K8JwyFOAXjGf0H9ItdgV-51hC5ygeJqmWenz6owOLuP4zYD6mMmZp2mA/s1600/hex+84+to+binary.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjfHFF9GESv2eTbxkEkga6vpVE0m_S_HiEOMrZJX8A2pEgWWi6Of64h7HbteMDS946ov6FfmHRJTV7ve5g2McM-K8JwyFOAXjGf0H9ItdgV-51hC5ygeJqmWenz6owOLuP4zYD6mMmZp2mA/s1600/hex+84+to+binary.png" /></a></div><div style="clear: both;">The most significant bit here has the value of one and therefore is set. This indicates that this <i>varint</i> includes, at least, the next byte <b>60 </b>which converted to binary:</div><div style="clear: both;"><br />
</div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik3Tp5yQJ7opdUrOijgX9FspYqyMN3hGn8wSs1vTBQLoj9eXANBUXVZ9BOph8MvCyS7LL1oiuFLWCxXcJ0b5ngrVeV_I2FUC6XMtMfWIkfEk_RqJXdNSRYrMv1k5HVLkWtd0MvEMWfGQHt/s1600/hex+60+to+binary.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEik3Tp5yQJ7opdUrOijgX9FspYqyMN3hGn8wSs1vTBQLoj9eXANBUXVZ9BOph8MvCyS7LL1oiuFLWCxXcJ0b5ngrVeV_I2FUC6XMtMfWIkfEk_RqJXdNSRYrMv1k5HVLkWtd0MvEMWfGQHt/s1600/hex+60+to+binary.png" /></a></div><div style="clear: both;">It can be seen that the most significant bit is zero and therefore not set. This byte therefore is not followed by another and is the last byte of this <i>varint</i>. To establish the value of this <i>varint</i> we now have to take the least significant 7 bits of each of the two contributing bytes and concatenate them together:</div><div style="clear: both;"><br />
</div><div style="clear: both;"><span class="Apple-style-span" style="color: red;">0000100</span><span class="Apple-style-span" style="color: blue;">1100000</span></div><div style="clear: both;"><span class="Apple-style-span" style="color: blue;"><br />
</span></div><div style="clear: both;">We discard the leading zeros and convert the binary 1001100000 to decimal, giving a value of 608. This <i>varint</i> represents the row ID and we can see in figure 1 that the row ID is confirmed as 608.</div><div style="clear: both;"><br />
</div><div style="clear: both;">The calculation we have carried out can be represented by a formula. If we say that the value of the <i>varint</i> is <b>N</b> and the unsigned integer value of the first byte is <b>x</b> and the unsigned integer value of the second byte is <b>y </b>we can use the formula:</div><div style="clear: both;"><br />
</div><div style="clear: both;"><b>N</b> = (<b>x</b>-128) x 128 + <b>y</b></div><div style="clear: both;"><b><br />
</b></div><div style="clear: both;">If we substitute the value of our unsigned integers 132 and 96 into the formula:</div><div style="clear: both;"><br />
</div><div style="clear: both;">(132-128) x 128 + 96 = 608</div><div style="clear: both;"><br />
</div><div style="clear: both;">This formula works for two byte <i>varints </i>that can represent a maximum value of 16383. I suspect we are not likely to encounter larger <i>varints </i>in the SQLite databases we have an interest in with the possible exception of SQLite databases used to store browser cache. It is also worth noting that the most significant bit if included and allowed to contribute to the unsigned integer value would have a value of 128 (hence the [x-128]). Therefore if the first byte of a <i>varint</i> is less than 128 you can exclude the possibility of there being a second byte in the <i>varint</i>.</div><div style="clear: both;"><span class="Apple-style-span" style="color: blue;"><br />
</span></div><div style="clear: both;"><b>Payload Header and Payload</b></div><div style="clear: both;">We have already looked at two of the four areas of interest within a cell, the payload length and row ID. Next up is the <i>Payload Header</i> and <i>Payload</i>.</div><div style="clear: both;"><br />
</div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgB8rcnb6ifGNKACqMHx0jgK5DOCkmnrCAXFDdjzqPw_62-KzUUpLRTbrWeb-bYx_rqdtHkVP-h9AYLX3sJQ7b1sG7dTWSEUiYTbZZcOE9LdDX4Modc7L5McRzgon-uv5ke5gWI9wG9GKKL/s1600/Payload+header+make+up.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgB8rcnb6ifGNKACqMHx0jgK5DOCkmnrCAXFDdjzqPw_62-KzUUpLRTbrWeb-bYx_rqdtHkVP-h9AYLX3sJQ7b1sG7dTWSEUiYTbZZcOE9LdDX4Modc7L5McRzgon-uv5ke5gWI9wG9GKKL/s1600/Payload+header+make+up.png" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><span class="Apple-style-span" style="font-size: small;"><b>Figure 6 Payload Header make up</b><br />
</span></td></tr>
</tbody></table><div style="clear: both;">Figure 6 shows the make up of the <i>payload header</i> of a record within the URLs table of the Google Chrome History SQLite database. The <i>payload</i> is the data forming the record stored in a serialized way with all the relevant data concatenated together. The <i>payload header </i>details how we can identify each field within the concatenated data and will vary from table to table, the contents of which is dictated by the fields required in each record. All payload headers will have however a <i>Payload Header Length</i> followed by one or more <i>Serial Type Codes</i>. The <i>Serial Type Code </i>is used to denote the type of data found in a field within the payload and it's length. All possible Serial Type Codes are <i>varints</i> and are detailed in a chart provided by SQLite.org at Figure 7:</div><div style="clear: both;"><br />
</div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJdCBODHZ2npO7j_FgUHD81IiiwrfkAdSr06p19c9dloMeyq6mrfMGOp_zocGJaraoHJ88AY3qnuk0nZF7hJ9-V9Ei-xBWnFoOdrELVACs-9TwhSXD7-HnDTxrX3h7TtvibZCEhxu7Yx4v/s1600/Serial+Type+Codes.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="355" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJdCBODHZ2npO7j_FgUHD81IiiwrfkAdSr06p19c9dloMeyq6mrfMGOp_zocGJaraoHJ88AY3qnuk0nZF7hJ9-V9Ei-xBWnFoOdrELVACs-9TwhSXD7-HnDTxrX3h7TtvibZCEhxu7Yx4v/s400/Serial+Type+Codes.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><b><span class="Apple-style-span" style="font-size: small;">Figure 7</span></b></td></tr>
</tbody></table><div style="clear: both;">Lets have a look at the Payload Header of our example record detailed in Figure 1.</div><div style="clear: both;"><br />
</div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj32VzmFCcGaB35-Rxk5kz9fk375l2zijloEKDCSaGff-2ri7B7jhLKZNRDYzy84PLnK_fGj3xhHEGGjrNq8bv-OC9MJ3DwVCRIhfY67U-mtsrYiy3o0E75ZHU3mAxw7KSmQLf2ampB0f-k/s1600/Payload+header+serial+types.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj32VzmFCcGaB35-Rxk5kz9fk375l2zijloEKDCSaGff-2ri7B7jhLKZNRDYzy84PLnK_fGj3xhHEGGjrNq8bv-OC9MJ3DwVCRIhfY67U-mtsrYiy3o0E75ZHU3mAxw7KSmQLf2ampB0f-k/s640/Payload+header+serial+types.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><span class="Apple-style-span" style="font-size: small;"><b>Figure 8</b></span></td></tr>
</tbody></table><br />
<div style="clear: both;">Figure 8 shows highlighted in blue and green the first three elements of the Cell make up shown in Figure 4 - the <i>Payload Length</i>, the <i>Row ID</i> and the <i>Payload Header. </i>We have already decoded the <i>Payload Length</i> <b>5B</b> and the <i>Row ID</i> <b>84 60</b>. The next byte <b>h09 </b>denotes the length of the <i>Payload Header </i>which is in this case 9 bytes (including the <i>Payload Header Length</i> byte). It can be seen therefore that the remaining 8 bytes shown in hex are <b>00</b>, <b>59</b>, <b>4D</b>, <b>01</b>, <b>01</b>, <b>06</b>, <b>01</b> and <b>01</b>. These bytes represent <i>varints </i>so we have to consider that a value may be represented by more than one byte, however in this case the unsigned integer value of each byte is less than 128. We can conclude therefore that each <i>varint</i> is only a single byte in length. To determine what each <i>varint</i> indicates we have to consult the Serial Type Code chart shown at figure 7. Each Serial Type Code details the type and length of the data in the <i>payload</i> that follows the <i>payload header</i>. The multi byte integers are decoded big endian.</div><div style="clear: both;"><ul><li><b>00 </b>This serial type code indicates that the first field is NULL and the content length is 0 bytes. We know that the first field in our record relates to Row ID (see figure 1) however the SQLite.org file format states <i>If a database table column is declared as an INTEGER PRIMARY KEY, then it is an alias for the rowid field, which is stored as the table B-Tree key value. Instead of duplicating the integer value in the associated record, the record field associated with the INTEGER PRIMARY KEY column is always set to an SQL NULL.</i></li>
<li><b>59 </b>This serial type code has a value of 89 which is greater than 13 and an odd number. The chart indicates therefore that this field is a text string (89-13)/2 bytes in length [38 bytes]</li>
<li><b>4D</b> This serial type code has a value of 77 which is greater than 13 and an odd number. The chart indicates therefore that this field is a text string (77-13)/2 bytes in length [32 bytes]</li>
<li><b>01</b> This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte</li>
<li><b>01</b> This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte</li>
<li><b>06</b> This serial type code has a value of 6 indicating the next field is an 64 bit integer using 8 bytes</li>
<li><b>01</b> This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte</li>
<li><b>01</b> This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte</li>
</ul><div>It can be seen that our <i>payload</i> is 82 bytes in length (38+32+1+1+8+1+1). The <i>payload header</i> was 9 bytes and therefore the overall <i>payload length</i> is 91 (82+9) bytes, as previously calculated, and represented by the byte <b>5B</b>.</div><div><br />
</div><table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: left; margin-right: 1em; text-align: left;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEig4BaoPrJA0mksc-VglngybfJcH6KS3mNEx1me2WAGHGatgGPpzTECe3sVzR3bIPEGc3zSschFsPAaPuXr4wlOR5H2iJcfoIZtvXTRNIDE_HT1hCnstpdWWTqD3wXCCrsSvlZyY25g_eKM/s1600/payload+in+encase.png" imageanchor="1" style="clear: left; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" height="182" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEig4BaoPrJA0mksc-VglngybfJcH6KS3mNEx1me2WAGHGatgGPpzTECe3sVzR3bIPEGc3zSschFsPAaPuXr4wlOR5H2iJcfoIZtvXTRNIDE_HT1hCnstpdWWTqD3wXCCrsSvlZyY25g_eKM/s640/payload+in+encase.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: left;"><span class="Apple-style-span" style="font-size: small;"><b>Figure 9</b></span></td></tr>
</tbody></table><div><br />
</div></div><div style="clear: both;">Figure 9 shows each element of the payload highlighted alternately in green and blue. The first element is <b>http://www.sqlite.org/fileformat2.html </b>38 bytes in length, the next element is <b>File Format For SQLite Databases </b>32 bytes in length. The next element is represented by the byte <b>01 </b>which denotes the visit_count of 1. This is followed by the byte <b>00</b> denoting the typed_count of 0. Next are the eight bytes <b>00 2E 01 6B 41 06 BD D4</b> decoded as a 64 bit integer big endian giving a value of 12949409092779476, the last_visit_time (stored in the Google format). The next byte is <b>00</b>, the hidden flag, followed lastly by <b>2E </b>decoded as 46, the favicon_ID. The next record in this case immediately follows at offset 3052 within the database page.<br />
<br />
<b>Notes</b><br />
I have glossed over some possible combinations of data found in stored records in order to try and simplify things a little. It is possible for a record to require more space than the space available in a cell within one database page. In this eventuality pages known as overflow pages come into play. I will leave any commentary on this to another day :-)<br />
<br />
<b>Carving Considerations</b><br />
It can be seen that each record of the Google Chrome History URL table may vary in content and length. This precludes simple carving of records using known headers. It may be possible to define a scheme to assist with carving however by focussing on the parameters of each element of the record. It is clear that for the Google Chrome History URL table the scheme would be fairly complicated, allowing for very large URLs and Page titles which may well induce many false positives. For databases using a simpler record structure things are a bit easier. A <a href="http://www.ccl-forensics.com/images/f3%20presentation3.pdf">presentation</a> presented by Alex Caithness of CCL details an approach that can be adopted for carving iPhone calls.db databases.<br />
<br />
<b>Deleted Data within Live Databases</b><br />
This area will require another blog post on another day! I am aware of two programs possibly written to recover this deleted data. <a href="http://chirashi.zensay.com/2010/11/recover-deleted-data-from-sqlite-databases/">SQL Undeleter from Chirashi Security</a> and <a href="http://www.ccl-forensics.com/Research-tools/epilog-sqlite-database-analysis-tool.html">Epilog from CCL</a>. If the developers will let me test these programs out I will report the results to you.<br />
<b><br />
</b><br />
<b>References</b><br />
http://www.sqlite.org/fileformat.html<br />
http://www.sqlite.org/fileformat2.html<br />
http://www.ccl-forensics.com/images/f3%20presentation3.pdf<br />
http://mobileforensics.wordpress.com/2011/04/30/sqlite-records/<br />
<br />
</div><div style="clear: both;"><br />
</div></div>DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com2tag:blogger.com,1999:blog-5057815281194312844.post-80190783412952244992011-05-04T12:09:00.000+01:002011-05-04T12:16:17.420+01:00SQLite Pointer Maps pages<p style="clear: both">This blog post complements and should be read in conjunction with the previous post <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/04/carving-sqlite-databases-from.html">Carving SQLite databases from unallocated clusters</a>. In that post I looked at the information available within an SQLite database that may assist in carving one from unallocated clusters.</p><p style="clear: both">You will remember from the earlier blog post that SQLite databases are divided into equally sized <em>pages and </em>SQLite database files always consist of an exact number of <em>pages. </em>The <em>page</em> size for a database file is determined by the 2 byte integer located at an offset of 16 bytes from the beginning of the database file. The first <em>page</em> in an SQLite database is numbered <em>page</em> 1.</p><p style="clear: both"><strong>Auto-vacuum capable</strong><br />Auto-vacuum capable SQLite databases make use of Pointer Map <em>pages </em>along with the other <em>page</em> types detailed in the earlier blog post. <em> </em>It is probably helpful to provide some information about what an auto-vacuum capable database is. </p><p style="clear: both">In a non-auto-vacuum-capable SQLite database when information is deleted the <em>pages </em>where<em> </em>it was stored are added to a list of free <em>pages </em>and these pages can be reused the next time data is inserted. Therefore, should data be deleted the file size of the database does not decrease. If a lot of data is deleted and it becomes necessary to shrink the database size the SQL VACUUM command can be run. This has the effect of reorganising the database from scratch and removing any free pages completely, thus making the database smaller.</p><p style="clear: both">When Auto-vacuum is enabled all free <em>pages</em> are moved to the end of the database file and the database file is truncated to remove the free <em>pages</em> at every transaction commit, thus removing free <em>pages</em> automatically. </p><p style="clear: both"><strong>Pointer Map Pages</strong><br />The purpose of the Pointer Map is to facilitate moving pages from one position in the database file to another as part of auto vacuum. When a page is moved, the pointer in its parent must be updated to point to the new location. Pointer Maps are used to provide a lookup table to quickly determine what a <em>pages</em> parent <em>page</em> is. They only exist within auto-vacuum capable databases, which require the 32 bit integer value, read big endian, stored at byte offset 52 of the database header to be non-zero.</p><p style="clear: both">In auto-vacuum-capable SQLite databases <em>page</em> 2 of the database is always a Pointer Map <em>page. </em>Pointer Map <em>pages</em> store a 5 byte record relating to every page that <strong>follows</strong> the Pointer Map <em>page. For example</em> if we have an auto-vacuum-capable database that has <strong>24 </strong><em><strong>pages</strong></em> (each of 4096 bytes in size) in total, <em>page</em> 1 will contain the database header and the database schema and the next <em>page, page </em>2, will be a Pointer Map <em>page. </em>This Pointer Map<em> page </em>will contain a 5 byte record for <strong>every one</strong> of the remaining <strong>22 </strong><strong><em>pages</em> </strong>taking up 110 bytes of space within the <em>page</em>. The first 5 byte record begins at the very beginning of the Pointer Map <em>page</em> and therefore in a 4096 byte <em>page</em> a maximum of 819 (4096/5) records can be stored. If the database has more than 821 <em>pages</em> (when using a <em>page</em> size of 4096 bytes) <em>page</em> 822 would be an additional Pointer Map page that would contain records for the next 819 <em>pages</em> <strong>following</strong> this second Pointer Map <em>page</em>. Further additional Pointer Map <em>pages</em> can be added in the same way. Pointer Map <em>pages</em> do not store records relating to Pointer Map <em>pages</em> or <em>page</em> 1 of the database.</p><p style="clear: both">Pointer Map 5 byte records are structured with 1 byte indicating a Page Type and then 4 bytes, decoded big endian, referencing the parent page number as follows:</p><ul style="clear: both"><li><strong>0x01</strong> 0x00 0x00 0x00 0x00<br />This record relates to a B-tree root page which obviously does not have a parent page, hence the page number being indicated as zero.<br /></li><li><strong>0x02</strong> 0x00 0x00 0x00 0x00<br />This record relates to a free page, which also does not have a parent page.<br /></li><li><strong>0x03 </strong>0xVV 0xVV 0xVV 0xVV (where VV indicates a variable)<br />This record relates to the first page in an overflow chain. The parent page number is the number of the B-Tree page containing the B-Tree cell to which the overflow chain belongs.<br /></li><li><strong>0x04 </strong>0xVV 0xVV 0xVV 0xVV (where VV indicates a variable)<br />This record relates to a page that is part of an overflow chain, but not the first page in that chain. The parent page number is the number of the previous page in the overflow chain linked-list.<br /></li><li><strong>0x05 </strong>0xVV 0xVV 0xVV 0xVV (where VV indicates a variable)<br />This record relates to a page that is part of a table or index B-Tree structure, and is not an overflow page or root page. The parent page number is the number of the page containing the parent tree node in the B-Tree structure.<br /><br /></li></ul><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjI12QAoHkkRm5WZJzuQxFEplVdXMuBHVIsicXhahjbvDevD9BzSx2zusUAuDk1qT1Pfv90zQ-dnMWPILQIqi6VQEfrxqBUCfk7rVb4s-deDMc6rIZP46Uag7vNU5_e6DYIhQUYjlqWT3GH/s800/Pointer_map_page_in_Encase.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhllUlksbr-rJcgGSwGfRvlpBc2SqWU9E7hQxahbx04GWGQOdmtIabDDZWRe6d4wTQNeSmkUYF3SPyd7fTAQYijBby8BaoE4IIsiSnTQQdQ9a5NVTfA4cxyhDIBqB7toUQerE6SMH8fncdz/s800/Pointer_map_page_in_Encase-thumb.png" height="570" align="left" width="311" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><strong>Figure 1</strong></p><p style="clear: both"><br /><br /><br />The screenshot at <strong>Figure 1 </strong>shows the Pointer Map page of an iPhone SMS.db which uses a page size of 4096 bytes. The Page Type bytes are highlighted in light blue and occur at every fifth byte. The byte highlighted in green (0x00) is the first byte of the sequence that is not one of the page type bytes as described above and therefore indicates that there are no more records stored in this pointer map as can be seen within the highlighted darker blue area.<br /><br /></p><p style="clear: both"><strong>Extrapolating the database size from the Pointer Map page</strong><br />If you count the Page Type bytes highlighted within <strong>Figure 1</strong> in light blue you will find there are 22. This is because we have 22 pages following the Pointer Map page and therefore require 22 records. This allows us to conclude that there are 24 pages in total within this database (page 1, the Pointer Map page and then the 22 pages). By examining the 2 byte integer located at an offset of 16 bytes from the beginning of the database file we have determined that the page size within this database is 4096 bytes. 24 multiplied by 4096 equals 98304. The file size of this particular database is therefore 98,304 bytes which can also be seen within <strong>Figure 1</strong>.</p><p style="clear: both"><strong>Carving Considerations</strong><br />To carve auto vacuum capable databases the following steps would be needed:</p><ul style="clear: both"><li>Identify first page of database by detecting the <em>SQLite format 3</em> header<br /></li><li>Establish <em>page size</em> by reading the 2 bytes at offset 16 as a 16 bit integer big endian </li><li>Check the 4 byte 32 bit integer at offset 52 for a non zero value indicating that the database is auto vacuum capable<br /></li><li>Go to page 2 of the database at Offset <em>page size</em><br /></li><li>If value is 0x01 or 0x02 or 0x03 or 0x04 or 0x05 set a counter to 1<br /></li><li>Move five bytes forward and if value is 0x01 or 0x02 or 0x03 or 0x04 or 0x05 increment the counter by 1<br /></li><li><strong>or</strong> if the value is not 0x01 or 0x02 or 0x03 or 0x04 or 0x05 begin the calculation of database file size using the formula<br /><br /></li><li><em>database size = (counter value + 2) x page size</em><br /></li></ul><p style="clear: both">The above discounts the possibility of their being more than one pointer map <em>page</em>. Some additional logic would be needed to cater for this eventuality. Pointer map <em>pages m</em>ay contain <em>page size/5 </em>records. If the counter increments to a point where it equals this value it would be necessary to locate the next pointer map <em>page </em>using the formula:</p><p style="clear: both"><em>next pointer map page number = (page size/5) + 2 + number of existing pointer map pages. </em></p><p style="clear: both">To calculate the offset to this <em>page </em>use the formula:</p><p style="clear: both"><em>offset = (page number-1) x page size.</em></p><p style="clear: both"></p><p style="clear: both"><strong>References</strong><br /><a href="http://www.sqlite.org/fileformat.html">http://www.sqlite.org/fileformat.html</a><br /><a href="http://www.sqlite.org/fileformat2.html">http://www.sqlite.org/fileformat2.html</a><br /><a href="http://www.sqlite.org/src/artifact/cce1c3360c">http://www.sqlite.org/src/artifact/cce1c3360c</a><br /><br /></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com1tag:blogger.com,1999:blog-5057815281194312844.post-90764123118460759052011-04-27T19:57:00.000+01:002011-05-09T11:19:06.321+01:00Carving SQLite databases from unallocated clusters<p style="clear: both"><em>Have you missed me?</em><br /><br /><strong>Background</strong><br />Carving SQLite databases from unallocated clusters is problematic because although these types of database have a header, there is no footer and the length of the file is not normally stored within the file either. Given that SQLite databases are used by so many programs now (e.g.Firefox, Google Chrome and numerous Mac OSX and IoS applications) to store data of forensic interest it would be useful to recover them from unallocated clusters. I am aware that there has been some comment in this area within our industry blogs and forums. A paper entitled <em>Forensic analysis of the Firefox 3 Internet history and recovery of deleted SQLite records </em>written by <em>Murilo Tito Pereira </em>became available in 2009 (at a cost) but my interest was piqued more recently when <em>Rasmus Riis</em> (who I believe works for Law Enforcement in Denmark) posted an enscript he had written - <em>Chrome SQlite db finder v1.4</em> to Guidance Software's enscript download center. <em>Rasmus Riis's</em> approach to carving SQLite files used by Google Chrome is to identify the header and then carry out additional checking throughout the file for known values within <em>page</em> headers. I had mixed results using this enscript and also wondered whether it could be adapted to search for other SQLite databases, in particular the SMS.db used by the iPhone. So as a result I took a closer look at the problem.</p><p style="clear: both"><strong>SQLite Database Structure and File Format</strong><br />The SQLite file format is well documented at <a href="http://www.sqlite.org/fileformat.html">http://www.sqlite.org/fileformat.html</a> and also at <a href="http://www.sqlite.org/fileformat2.html">http://www.sqlite.org/fileformat2.html</a>. What I will try to do here is pick out the salient points that may be relevant to carving SQLite files from unallocated clusters, and also provide some commentary where it may be useful.</p><p style="clear: both"><strong>Size and numbering</strong></p><ul style="clear: both"><li>The entire database file is divided into equally sized <em>pages - </em>SQLite database files always consist of an exact number of <em>pages</em></li><li>The <em>page </em>size is always a power of two between 512 (2<sup>9</sup>) and 65536 (2<sup>16</sup>) bytes<br /></li><li>All multibyte integer values are read big endian</li><li>The <em>page</em> size for a database file is determined by the 2 byte integer located at an offset of 16 bytes from the beginning of the database file<br /></li><li><em>Pages</em> are numbered beginning from 1, not 0<br /></li><li>Therefore to navigate to a particular <em>page </em>when you have a <em>page</em> number you have to calculate the offset from the start of the database using the formula:<br /><em>offset = (page number-1) x page size</em></li></ul><p style="clear: both"><strong>Possible Page Types</strong><br />Each page is used exclusively to store one of the following:</p><ul style="clear: both"><li>An index B-Tree internal node<br /></li><li>An index B-Tree leaf node<br /></li><li>A table B-Tree internal node<br /></li><li>A table B-Tree leaf node<br /></li><li>An overflow page<br /></li><li>A freelist page <br /></li><li>A pointer map page<br /></li><li>The locking page<br /></li></ul><p style="clear: both">However not every database will include all of these items.</p><p style="clear: both"></p><p style="clear: both"><strong>The first <em>page</em> (<em>page</em> 1)</strong><br />The first <em>page</em> of the database is a special page for two reasons; it contains within the first 100 bytes of the <em>page</em> the <strong>database header</strong> and it also contains the Database Schema (the structure of the database [tables, indexes etc.] described in formal language).</p><p style="clear: both"><strong>The database header</strong> begins with the following 16 byte sequence:<br /><br /><strong>0x53 0x51 0x4c 0x69 0x74 0x65 0x20 0x66 0x6f 0x72 0x6d 0x61 0x74 0x20 0x33 0x00</strong></p><p style="clear: both">which when read as UTF-8 encoded text reads <em>SQLite format 3 </em>followed by a nul-terminator byte.</p><p style="clear: both">Other significant values at offsets within the <strong>database header</strong> are as follows:</p><ul style="clear: both"><li><strong>Offset 16 2 bytes 16 bit integer read big endian</strong> <br />Page Size<br /></li><li><strong>Offset 28 4 bytes 32 bit integer read big endian</strong><br />The logical size of the database in pages which is only populated when the database was last written by SQLite version 3.7.0 or later. This field is only valid if it is nonzero and in all examples of SQLite databases I have examined this value was zero, so unfortunately not as exciting as it first appears!<br /></li><li><strong>Offset 32 </strong><strong>4 bytes 32 bit integer read big endian</strong><br />Page number of first freelist trunk page<br /></li><li><strong>Offset 36 </strong><strong>4 bytes 32 bit integer read big endian</strong><br />Total number of freelist pages including freelist trunk pages<br /></li><li><strong>Offset 52 </strong><strong>4 bytes 32 bit integer read big endian</strong><br />The highest numbered root page number if the database is auto-vacuum capable, for non-auto-vacuum databases, this value is always zero. The majority of the databases we are likely to be interested in are non-auto-vacuum databases.<br /><br /></li></ul><p style="clear: both"><strong>B-Tree <em>pages</em><br /></strong></p><p style="clear: both">The SQLite.org file format notes helpfully state that:</p><p style="clear: both"><em>A large part of any SQLite database file </em><em>is given over to one or more B-Tree structures. A single B-Tree structure is stored using one or more database pages. Each page contains a single B-Tree node. The pages used to store a single B-Tree structure need not form a contiguous block.</em></p><p style="clear: both">So from a carving perspective we note that most of what we wish to carve are B-Tree pages but they are not necessarily stored contiguously. We can however identify B-Tree pages because they have a <em>page </em>header 8 bytes in length if the page is a leaf node page and 12 bytes in length if the page is an internal node page. In all <em>pages, </em>with the exception of <em>page </em>1, the header starts at the beginning of the page at offset 0. On <em>page </em>1 the header starts at offset 100.</p><p style="clear: both">The first byte of all B-Tree <em>page</em> headers is a flag field, each flag is detailed as follows:</p><ul style="clear: both"><li><strong>0x02</strong><br />flag indicating index B-Tree internal node<br /></li><li><strong>0x0A</strong><br />flag indicating index B-Tree leaf node<br /></li><li><strong>0x05</strong><br />flag indicating table B-Tree internal node<br /></li><li><strong>0x0D</strong><br />flag indicating table B-Tree leaf node<br /><br /></li></ul><p style="clear: both">These flags therefore allow us to potentially identify B-Tree pages (of all types) by examining the first byte of each <em>page </em>to see if it is either 0x02, 0x0A, 0x05 or 0x0D.</p><p style="clear: both">The B-Tree <em>page</em> header also contains some other potentially useful values (offsets from start of page):</p><ul style="clear: both"><li><strong>Offset 1 2 bytes 16 bit integer read big endian</strong> <br />Byte offset of first block of free space on this page (0 if no free blocks)<br /></li><li><strong>Offset 3 2 bytes 16 bit integer read big endian</strong><br />Number of entries (cells) on this page<br /></li><li><strong>Offset 5 2 bytes 16 bit integer read big endian</strong><br />Byte offset of the first byte of the cell content area relative to the start of the page. If this value is zero, then it should be interpreted as 65536<br /></li></ul><p style="clear: both"><strong>Freelist pages</strong></p><p style="clear: both">Once again the SQLite.org file format notes help us out:</p><p style="clear: both"><em>A database file might contain one or more pages that are not in active use. Unused pages can come about, for example, when information is deleted from the database. Unused pages are stored on the freelist and are reused when additional pages are required.</em></p><p style="clear: both"></p><p style="clear: both"><em>Each page in the freelist is classified as a freelist trunk page or a freelist leaf page. All trunk pages are linked together into a singly linked list. The first four bytes of each trunk page contain the page number of the next trunk page in the list, formatted as an unsigned big-endian integer. If the trunk page is the last page in the linked list, the first four bytes are set to zero.</em></p><p style="clear: both">The operation of the freelists might be better understood by a quick forensic examination of them:</p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvEHJ-H-gkmQEuwrD4emTPCqmpG4hGoOMaY-jgbULDZXC7Sj9T3O7Vap-niXLBehfmRtH8A222UjdBZJ08ru6nNqAWFn8vxkKLmI51sDG5n7HqfsVHzc7GoFh-l3J7VZChkLo_gycX-u5R/s800/Database_Header_offsets_32_and_36.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjS4HUj8iR_WgLLfHZ9GhZMWWkchO-9QmaHFdm4jScHJGPN73WWj6PsG4Ez2A8XM6YBjT5AhsNfXPdLVX7HNUnQXqCJuRPrCvhP0svjY7UPFo_7iSecg2kxecxNplEAvdFGAgl7wu4cul-U/s800/Database_Header_offsets_32_and_36-thumb.png" height="160" width="285" style=" text-align: center; display: block; margin: 0 auto 10px;" /></a>The four bytes highlighted in blue are at offset 32 within the database header and decoded as a 32 bit integer big endian give a decimal value of 61 - this is the page number of the first freelist trunk page. The four bytes highlighted in green are at offset 36 within the database header and decoded as a 32 bit integer big endian give a decimal value of 70 - this is the total number of free pages including freelist trunk pages.</p><p style="clear: both">The page number of the first freelist trunk page is 61. To calculate the offset from the start of the database for this page we use the formula <em><strong>offset = (page number-1) x page size</strong> </em>which in this case is <strong>(61-1) x 4096 = 245760.</strong></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhCbF5bREbs0dzPZORUGA5ESiTP-E-5kSyHJjMBQWE6e_YsZ6BNtHQ3QoFcPqJz2GAYsEVz8jIozobg0pEkoU60hKYNLeTWWTPB3uC53j2x6eQCOQ7_qJof32oEIc6eEBfJdbf_vbejyAXe/s800/Freelist_trunk_page_array-full.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjkcNX2Sk79CzAoi66gtqY0kU-sREYCkPHowCW4SatyivHJDG037RuuBGmBGM3JCXUbQhFfQqr7DTqTrKipjLvsqdPJRqWOxv1ggqO8a5iTdNb91JMvqV-Od7uNxNzHM-QMLN8wG4UlhUXO/s800/Freelist_trunk_page_array-thumb.png" height="243" width="379" style=" text-align: center; display: block; margin: 0 auto 10px;" /></a>The offset 24570 takes us to start of the first freelist trunk page. There we find an array of 4 byte big endian integers. The first four bytes (highlighted in green) decoded big endian denote the page number of the next freelist trunk page - in this case the value of the first four bytes is zero indicating that there is no more free freelist trunk pages. The second four bytes (highlighted in blue), in this case <strong>0x00 0x00 0x00 0x45</strong> when decoded as a 32 bit integer big endian give a value of decimal 69 - this is the number of leaf page pointers to follow. The remaining 69 blocks of 4 bytes (alternately highlighted in green and blue in the screen shot) each represent, when decoded as a 32 bit integer big endian, the page number of a free page. Examination of each free page revealed that the entire page had been zeroed out - although this may be a function of the application using the database, not a function of SQLite itself.</p><p style="clear: both"><br /><strong>Pointer map pages</strong><br />Pointer map pages will only exist if the database is auto-vacuum capable and the value within the 4 bytes of the database header at offset 52 is non zero. In a database with pointer map pages, the first pointer map page is page 2. The first byte of a pointer map page is one of five values 0x01, 0x02, 0x03, 0x04 or 0x05. Many of the databases we have a forensic interest in are not auto-vacuum capable and therefore do not have pointer map pages, however where they do (iPhone SMS.db for example) it is possible to calculate the length of the of the SQLite database by extrapolating information from the pointer map page entries. I will cover this in my <a href="http://forensicsfromthesausagefactory.blogspot.com/2011/05/sqlite-pointer-maps-pages.html" target="_blank">next blog post</a>.</p><p style="clear: both"><br /><strong>Locking Page</strong><br />The locking page is the database page that starts at byte offset 2<sup>30</sup> (1,073,741,824) and always remains unused (i.e all zeros). Most databases will not be big enough (> 1GB) to require a locking page.</p><p style="clear: both"><br /><strong>Overflow pages</strong><br />Once again the SQLite.org file format notes help us out:<br /><br /><em>Sometimes, a database record stored in either an index or table B-Trees is too large to fit entirely within a B-Tree cell. In this case part of the record is stored within the B-Tree cell and the remainder stored on one or more overflow pages. The overflow pages are chained together using a singly linked list. The first 4 bytes of each overflow page is a big-endian unsigned integer value containing the page number of the next page in the list. The remaining usable database page space is available for record data.</em></p><p style="clear: both">We can calculate that for the first byte to be any value other than 0x00 there must be at least 16,777,216 pages within the database (0x01 0x00 0x00 0x00 decoded big endian). At a page size of 4096 bytes this would equate to a database size of 64 Gigabytes. In most cases therefore we can discount the first byte of overflow pages being anything other than 0x00.</p><p style="clear: both"><br /><strong>So how does this help with carving SQLite databases then?</strong><br />We can use the database header and the first byte value of each <em>page</em> thereafter to determine whether the data within each <em>page</em> size block is valid. So from a carving perspective we can identify the first <em>page</em> with the database header, calculate the <em>page</em> size, read the next <em>page</em> and validate the first byte and so on until the <em>first byte validation</em> fails. </p><p style="clear: both">This essentially is what <em>Rasmus Riis's </em><em>Chrome SQlite db finder v1.4 </em>enscript does for SQLite databases created by the Google Chrome web browser. His description of the enscripts functionality states that it checks the first byte of each <em>page, </em>other than the first page, for the values <em>13,10, 2, 5 or 0. </em>Convert these values into hex and you get 0x0D, 0x0A, 0x02, 0x05 and 0x00. The first four of these values are the flags found at the first byte of the B-Tree page headers discussed above. Additionally he checks for 0x00 which may well be the first byte of either a free page or an overflow page. The script does not however allow 0x01, 0x03 or 0x04 to be the first <em>page</em> byte. This therefore does not allow for an auto-vacuum capable database. The databases used by Google Chrome are not auto-vacuum capable, however other databases such as the iPhone SMS.db database are. <em><br /></em></p><p style="clear: both"><em>Rasmus's en</em>script also carries out a test of the two bytes at offset 100 within the first database <em>page</em>. The enscript according to the description in the download center looks for the values 2243, 3853 or 3331. The coding however shows that it checks for 3343 or 3853 or 3331 decoded big endian. Converted to hex the first two bytes would be<strong> 0x0D 0x0F</strong> or <strong>0x0F 0x0D</strong> or <strong>0x0D 0x03. </strong>I am not sure what <em>Rasmus</em> had in mind for the second value 3853 (which is <strong>0x0D 0x0F </strong>converted little endian) but focussing on the first and the third pairs of two bytes the script is taking the flag byte and the first byte of the two bytes used to store the Byte offset of first block of free space on the <em>page. </em>The first <em>page</em> of all SQLite databases beyond the 100 byte database header store the database schema and are therefore constant (in other words because each particular database has a unique set of tables and indexes the first page of a particular database does not change from instance to instance). Because the database schema does not change the combining of the first and second bytes seems to work in order to identify Chrome databases.<br /><br />This lead me on to consider whether an analysis of the following values within the B-Tree page header of the first page containing the database schema would allow the identification of other types of SQLite databases. The following table appears to suggest that it would be possible to establish a <em>fingerprint</em> for each database type. I have not collected enough test data to be certain about this yet.</p><p style="clear: both"><a href="http://lh5.ggpht.com/_QfcS6HZ5Sws/TbhLH7md8WI/AAAAAAAABQQ/IYRFPbL2FIE/s800/known_B-tree_page_header_offsets.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgQwuqG6Ekb4fgvO5w0a-5t4H2FFbfI9BLV_hvcir8NjjnxAazyg_ZZAIxlK0OL5tI0mViqycs-PTUVbG_UhE6og1LQa8XP6QWjqqBzRc0NRix-iUvGq2ma53CdDD8_1s5h0AWWmVH99yV/s800/known_B-tree_page_header_offsets-thumb.png" height="135" width="380" style=" text-align: center; display: block; margin: 0 auto 10px;" /></a>With regards to <em>Rasmus's en</em>script because he was kind enough to share and also not Enpack it is possible to make some small changes to the code to allow it to parse unallocated for all types of SQLite.db. I am in touch with my programming friends to create a script that can carve and identify SQLite databases from the <em>fingerprint</em> discussed above and also include a greater amount of error checking.</p><p style="clear: both"><strong>Other stuff of note</strong><br />When you examine data within SQLite databases have you noticed that most of the meaningful stuff is bunched up at the end of each <em>page</em>? The SQLite.org file format notes help us out here:</p><p style="clear: both"><em>The total amount of free space on a b-tree page consists of the size of the unallocated region plus the total size of all freeblocks plus the number of fragmented free bytes. SQLite may from time to time reorganize a b-tree page so that there are no freeblocks or fragment bytes, all unused bytes are contained in the unallocated space region, and all cells are packed tightly at the end of the page. This is called "defragmenting" the b-tree page.</em></p><p style="clear: both"><strong>To Do</strong><br />I have not as yet covered the part the journal files may play in the recovery of SQLite data from unallocated, a future post perhaps.</p><p style="clear: both"><strong>Thanks</strong><br />to <em>Rasmus Riis </em>for sharing his enscript<br />and to Chris Vaughan for his help in firming up some of the theory.</p><p style="clear: both"><strong>References</strong><br /><a href="http://www.sqlite.org/fileformat.html">http://www.sqlite.org/fileformat.html</a><br /><a href="http://www.sqlite.org/fileformat2.html">http://www.sqlite.org/fileformat2.html</a><br /><a href="http://www.sqlite.org/requirements.html">http://www.sqlite.org/requirements.html</a><br /><a href="http://www.sqlite.org/hlr30000.html">http://www.sqlite.org/hlr30000.html</a><br /><a href="https://support.guidancesoftware.com/forum/downloads.php?do=file&id=1116">https://support.guidancesoftware.com/forum/downloads.php?do=file&id=1116</a></p><p style="clear: both"><br /><br /></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com5tag:blogger.com,1999:blog-5057815281194312844.post-7695548509498975162011-01-04T16:26:00.000+00:002011-01-04T16:36:05.394+00:00Reporting and Exporting Emails from Encase<p style="clear: both">Regular readers will know that I champion Encase for most forensic tasks but I have to admit that my favourite forensic tool does not handle the investigation of email very well.</p><p style="clear: both">My friend Oliver Smith, over at Cy4or, had cause to run a keyword search across a number of emails. These emails were contained in a number of email containers including dbx and pst files and the Encase email search had been carried out. The emails were reviewable in the records tab. There was a need however for the client to review emails that contained certain keyword hits. Encase provides an export to .msg facility whereby emails can be exported in the .msg format allowing a review using Microsoft Outlook. It is a therefore a simple task to filter the records tab to display only email with search hits (that is those with a value in the Search Hits column). Then by selecting those records you can export them as .msg files.</p><p style="clear: both">The problem with this approach is that it is difficult to marry up the exported .msg files to a report detailing each msg files provenance. So in a case where many thousands of emails have been exported it is a real pain to provenance the relevant emails after the client's review. Depending on the email container concerned (e.g. pst, dbx etc.) Encase names the .msg file either by its subject or by some arbitrary description (Inbox.dbx-0.msg, Inbox.dbx-1.msg and so on). In situations where the client has copied notable emails out of the original export directory it can be very difficult to quickly trace the source email container.</p><p style="clear: both">To address this problem Oliver has written an enscript to export selected emails to .msg along with a report detailing their provenance.</p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgKtG93GnxIokS6vqHavMejQ4xlqjBZV1wDSQGRGuwGrv_dUfVkSe6qJeeDQFupqbxw1SyR4UmTf2U9Llbu8MBVqOpY0PXrR11cW29hG775d5Pirsm9uReOWcUqYWfB0kjS-ME-60KJ_zJu/s800/Screen_shot_2011-01-04_at_16.04.45.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj548MZ7Mw7yHCwOy1jhJ9AXVz4JfXPL0TGs36in6tkt2ZjOyhDZFc25Epsh7Ry-1o9viX-cW9fg7e96i9vNk4gQKAHg6UX5p9fLo_rSGQgqlmqbeK4Sw8oA-JcpKWf6SjhQ8lR_qNeH2JH/s800/Screen_shot_2011-01-04_at_16-thumb.04.45.png" height="59" align="left" width="154" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br style="clear: both" />The html report contains hyperlinks to each message along with the emails provenance and it's metadata. The file name of each exported email marries up to the reference number in the report.</p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgkDdLNGg6Twae5w6W5-2Nbl1ciWHG90qkU6wfGmB7csbYTdGJ3kYOt0Ohxaj8ZqHs4BXz_0Ed7UgFIPkSDWN2dZyXuRIh_Lb4ALZAZ-XYKoIT5KVWjeuDrCfcaAojoubhbHwhsur_l0FQ6/s800/Screen_shot_2011-01-04_at_16.12.34.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgJ180Hm3SPGWgmhcMD1SHrT1UehL8dW0xsKSeK_TfZB514wnXXYVNQPYkJ28Qjju8P1GbqcBmI_HguUY8I2FUtEsrivSUS9_GNWzmg2JqAXpzqqGTeX0Zcl7n6Lhb7VUU-XsnCx8xijGjt/s800/Screen_shot_2011-01-04_at_16-thumb.12.34.png" height="354" align="left" width="500" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br style="clear: both" />As always if you would like a copy please email me.</p><p style="clear: both">Richard Drinkwater</p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com2tag:blogger.com,1999:blog-5057815281194312844.post-86846967629723278732010-11-08T23:14:00.000+00:002010-11-08T23:15:00.925+00:00Storage in Forensic Labs<p style="clear: both">As you probably appreciate the Sausage Factory type of computer forensics lab has to store and retain vast quantities of data. In the early days, even in the Sausage Factory, we imaged individual hard drives to individual hard drives. But because of the volume of data and the economics of this methodology we realised that we had to use some form of centralised storage. That was in 2002 and since then we picked up a few tips along the way. </p><p style="clear: both">I know of a number of LE labs that have invested large sums (£100k plus) buying their storage area networks. Unfortunately further down the road they could not afford to increase capacity, had maintenance issues, or had other difficulties exacerbated by the shear complexity of their set up. At the other end of the scale I know of sizeable outfits who stick to imaging to hard drives because they believe that they would never acquire the budget to go down the centralised storage route. </p><p style="clear: both"><a href="http://lh4.ggpht.com/_QfcS6HZ5Sws/TNUQKAjeHJI/AAAAAAAABKY/fyp8TE2RTxQ/s800/Jetstors1.jpg" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwfUUZzzVaCCZDxWgEA_eGcHml3Er0JqcX2tl3dxgkWqpK2D6GazbUKMScCK1-1wRZpzZ_mNFpjTRIXUVBtzWgvazOznbGSRfhdrEzSRkVy_Z-hSC8m2J2ySlRiBcWRSLO6zpxMw4V6fRG/s800/Jetstors1-thumb.jpg" height="600" align="left" width="183" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a>I believe there is a middle ground. It is possible to buy 26TB of useable RAID6 storage (32TB raw), a Server and a backup solution for circa £15k. This solution is scalable with further units of 26TB useable storage costing circa £7k each. With a sensible set of operating procedures this type of solution will remain serviceable and fit for purpose for a number of years. <br /> <br />The observant amongst you will have counted nine raid enclosures in the picture. The youngest unit is a Jetstor 516F which when equipped with 16 2TB enterprise class SAS hard drives provides 26TB usable storage and costs less than £10k. The oldest Infortrend unit is over five years old (and does not store production line data any longer). None of these units have ever lost data. They routinely recover from the inevitable hard drive failures. Although these units are not in the same league as EMC et al they are manufactured for the enterprise and in my experience have longevity built in. It is possible to provide similar levels of storage even cheaper with consumer grade equipment but this would probably be a false economy. <br /><br />All of these units are directly attached (via fibre) to a server. I have found that both Intel and HP manufacture (and support) servers that will probably last forever. Again I look after servers that have not missed a beat in five years. <br /><br />Although I have found that this type of kit will last I think it is sensible to plan to cycle replacement of primary production line equipment over a three to four year period. Since 2002 I have learnt a lot about this type of kit but have also found that choosing a supplier that will hold your hand when necessary can be particularly useful. In the UK I have found that <a href="http://storage.vspl.co.uk/" target="_blank">VSPL</a> understand the needs of LE computer forensic labs and most importantly have always been available to support me when required.<br /><br />This type of setup, in my experience, has worked well in supporting the production line nature of our forensics work. However a certain way of operating it is required. Which if I had to sum up in two points the first is that storage performance is best alongside processor performance - on the forensic workstation, and secondly if you want data resilience keep two copies of your data (in one form or another) at all times.<br /><br />Obviously there is a little bit more to it than that. If you are interested in finding out more please let me know,</p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com7tag:blogger.com,1999:blog-5057815281194312844.post-71864200196845840262010-10-09T10:24:00.000+01:002010-10-11T14:49:49.551+01:00FTK Imager 3<p style="clear: both">FTK Imager has always been the <em>crème de la crème </em>of free forensic tools and now with the introduction of <a href="http://www.accessdata.com/downloads/current_releases/imager/AccessData%20FTK%20Imager.exe" target="_blank">FTK Imager 3</a> it is even better.</p><p style="clear: both">Access Data have added some amazing functionality to this programs already extensive list of capabilities - <a href="http://www.apple.com/pr/library/2010/01/27ipad.html" target="_blank">in fact to steal a phrase</a> - its almost magical and it is certainly available at an unbelievable price. So what am I referring to? </p><p style="clear: both">The answer of course is the new image mounting feature which allows a user to mount an image as a drive or physical device. Encase evidence files, Smart image files, Advanced Forensic Format images and dd images are supported. Additionally Encase Logical Evidence Files and Access Data's AD1 custom content images can be mounted logically. Full details in the <a href="http://www.accessdata.com/downloads/current_releases/imager/FTKImager_ReleaseNotes.pdf" target="_blank">Release Notes</a>.</p><p style="clear: both">This functionality is accessed via <em>File/Image Mounting</em></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHrl2KPt2J81s2cisvKyhnxQ0ju_jm1e4odewk9mR-Ewe4adhEqBsx2gzTW0lK7Y1jkXKWUhHH-YvG87_33mqzlAI9dtljKpfbsXAxbUyc2lPOAGS2LzKZUlLEdduo41Iw0s6bjLJGQHQe/s800/FTK_image_mounter_dialogue.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiK6GaS5MJt-mls8KWmAbCuYhw-5-k8JTx4zD6_R0zQWQJb026zaAqaApL57IScDW5S4NfLJonCNU2tRu1dJD2uyVnRP5hgRjBet0stX7BxIcLt2BB8QvWhkzSvZI44QTIFrpYq_3H6MoMv/s800/FTK_image_mounter_dialogue-thumb.png" height="208" align="left" width="500" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>In this screen shot I have chosen to mount a drive from a Mac which includes a Bootcamp partition</em><br /><br /><br /></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBd7xRfJ7-FNiHPMtUbtdjwaNQ1pmhvYv7H834s8INUDOjFeNxWLXx1j9jhlrOslGeR9ZprnX3m9uH4Zs0mw4WG6v72szudvmvmJBtVUMl5fBY45e9dN4eTBWi-3qbNrVFe6K63DNHxQfl/s800/FTK_image_mounter_dialogue2.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgH4R9IcEAXLqylO4TX0RWmLCLaFRvtShIoT037eZ1adQiBewjBjRU7i3zrh1cBqyIN2tuHkDvfDdP9QQwh7Zg3-3SCteevbmFH6fTGsG1kNxeHBS0VsYADg3YCx1zktjl1cPBIrHQhQO7F/s800/FTK_image_mounter_dialogue2-thumb.png" height="147" align="left" width="370" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>This resulted in the EFI partition, the HFS+ partition and the NTFS Bootcamp partition all being given a drive letter. The whole drive is allocated the Physical Drive Number 4 in this example.<br /></em></p><p style="clear: both">All of these resources are now available natively upon the machine that FTK Imager 3 is running on. The Physical Disk however is not listed in Disk Management nor does this functionality appear to install any devices within Device Manager. </p><p style="clear: both">Logical mounting of non windows partitions (HFS+, EXT3 et al) will present an explorer view of these file systems as FTK imager itself sees them (<em>à la</em> Encase VFS).</p><p style="clear: both">This functionality provides many benefits and at first look at least, renders the costly alternatives of PFS/VFS and Mount Image Pro redundant. It also raises the bar in how we can construct virtual machines from images due to the ability to mount more than one drive at once, thus simplifying the creation of multi drive VMs. The functionality also facilitates non techies (lawyers, fraud investigators et al ) to easily peruse images.</p><p style="clear: both">FTK Imager 3 also introduces support for VXFS, ex FAT and EXT4 file systems. As we sometimes say in England it's <a href="http://en.wikipedia.org/wiki/Bollocks#.22Dog.27s_bollocks.22" target="_blank">the dogs...</a></p><p style="clear: both"><a href="http://www.phrases.org.uk/meanings/dog" s%20bollocks.html'="" link_target="_blank"></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com4tag:blogger.com,1999:blog-5057815281194312844.post-13940011882094148212010-09-07T06:14:00.000+01:002010-09-07T06:22:53.419+01:00Hiberfil Xpress<p style="clear: both">Departing on platform 2 .... I seem to have lost my train of thought ..... ever since I started drafting this post I have had to cope with lyrics of Crosby, Stills and Nash's <a href="http://www.oldielyrics.com/lyrics/crosby_stills_nash/marrakesh_express.html" target="_blank">Marrakesh Express</a> floating around in my brain. OK I know I've lost two thirds of my readership already - Crosby Stills and WHO?</p><p style="clear: both">This post, once I've overcome a touch of nostalgia, is about the use of compression by Microsoft in the Hiberfil.sys file. From a forensic point of view this fact can be quite important and I have seen reference to this compression in a few of the other forensics blogs as the result of the work of <a href="http://sandman.msuiche.net/docs/SandMan_Project.pdf" target="_blank">Matthieu Suiche</a>. I also know that functionality exists in Xways to decompress Hiberfil.sys but until now this functionality was absent in Encase.</p><p style="clear: both">The reason Microsoft uses compression is to <a href="http://download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/HiberFootprint.docx" target="_blank">minimise the footprint of Hiberfil.sys</a>. The compression seeks to reduce Hiberfil.sys to about 75% of physical memory size. The presence of this compression can be identified easily - it exists in chunks typically 16 x 4096 bytes in size, each chunk having a header <strong>\x81\x81xpress </strong>. Not all hiberfil.sys files utilise this compression.</p><p style="clear: both">The reason it matters to us can be demonstrated by looking at a fairly common task for us forensicators; finding traces of Windows Live Messenger conversations. In the worst case scenario, when logging is turned off and the user has not saved their conversation, traces of conversations may only be found in memory (or artefacts of memory created on disk). Hiberfil.sys is used to store the contents of memory when the computer concerned is hibernated and therefore potentially may contain <a href="http://en.wikipedia.org/wiki/Microsoft_Notification_Protocol" target="_blank">Microsoft Notification Protocol</a> messages relating to WLM conversation. A fairly typical grep keyword used to find these traces is <strong>\x20PF= . </strong>When run over a hiberfil.sys containing xpress compression results may appear similar to the following screenshot:</p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgINevv6BEgA6XDgUIk2plvQCcxoCNM90txzIVw4FBm329o21CXwgvzv4N5aTVtCwm5IHmirn52WXrsBIVWf6UhsOOvDrXiJxAXT7fSrlMTw5Pv_O2zWHwCe_HqfHHcZFmbQJOCtQaxaiz0/s800/xpress_uncoded_MSNP.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmOMKelUtme3y5Hk1rG3y-UnS5SWyw6iyDLVaPeFZiB-OFlVeVOU9_-DS3Tt23H3nOjA8ZdJ0Zr8g729x1kUvUGXYpxSEn2YpoD9-FSp3Pi_Wi5GEWBXRn76fF7UYIyepmXY-lOVDBfJFK/s800/xpress_uncoded_MSNP-thumb.png" height="107" align="left" width="500" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br style="clear: both" />It can be seen that the message and the surrounding MSNP is a little garbled. This is because this message is within a xpress compressed block. Decompressing the block and viewing the same message results in:<br /><br /></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg8t17wqrq13o-qwq4NnloqSKTX1qqeaZInP24os0W1p8P3LQagNx_E_n7ZjK9pVsXpcAZ1fUj4Zc5G8hRlk1-J57vsWWpGK24PwQ4BgUfEasIf8ms84YbgDgZ0uuLieJnBsAutgMEJdETj/s800/xpress_decoded_MSNP.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjoisKT1S22Iedx_EvBTz8enIK6MtVtApWt69U31vBFvsu_3zzm1NllUTVNfidznc1fBsVkoSEU8TGDKMNnbqyBRv0tDwn5b6E2AM82F7GI2UeGtwxrQeFK_XSVpjxnPJE3uuosgncs7oyw/s800/xpress_decoded_MSNP-thumb.png" height="94" align="left" width="500" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br style="clear: both" />It can be seen that the MSNP and the message is now in plain text. Until now achieving the decompression for Encase users required the use of another tool but I am pleased to report that after discussing this issue with Guidance Software's Simon Key he wrote an enscript for this purpose. The script can decompress all xpress blocks within hiberfil.sys and write them out to a logical evidence file. Alternatively it will decompress each block in turn and then perform a keyword search against it. Blocks containing search hits are written into a logical evidence file. The script is available at <a href="https://support.guidancesoftware.com/forum/downloads.php?do=file&id=942" target="_blank">GSI's download center</a>.</p><p style="clear: both">Finding traces of MSNP is only one use, you can find index.dat contents, Limewire search terms and many other interesting artefacts in Hiberfil.sys - happy searching!</p><p style="clear: both"><strong>References</strong><br /><a href="http://www.forensicswiki.org/wiki/Hiberfil.sys" target="_blank">http://www.forensicswiki.org/wiki/Hiberfil.sys</a><br /><a href="http://msdn.microsoft.com/en-us/library/ee915356(PROT.13).aspx" target="_blank">http://msdn.microsoft.com/en-us/library/ee915356(PROT.13).aspx</a></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com2tag:blogger.com,1999:blog-5057815281194312844.post-70253471198565178652010-08-06T14:08:00.000+01:002010-08-07T09:39:24.817+01:00USN Change Journal<p style="clear: both">This post includes</p><ul style="clear: both"><li>a new method to recover USN Change Journal artefacts from unallocated<br /></li><li>some background information</li><li>some commentary on benefitting from the existing work of Lance Mueller and Seth Nazzaro<br /></li></ul><p style="clear: both"><strong>Background</strong><br />The examination of USN Change Journals is nothing new and was commented on as long ago as <a href="http://www.forensickb.com/2008/09/enscript-to-parse-usnjrnl.html" target="_blank">September 2008 in Lance Mueller's blog</a>. My interest was piqued more recently when <a href="http://windowsir.blogspot.com/2010/07/links.html" target="_blank">Harlan Carvey discussed the python script</a> written by Seth Nazzaro to parse these Journals. </p><p style="clear: both">The update sequence number (USN) change journal provides a persistent log of all changes made to files on the volume. As files, directories, and other NTFS objects are added, deleted, and modified, NTFS enters records into the USN change journal, one for each volume. Each record indicates the type of change and the object changed. New records are appended to the end of the stream. Programs can consult the USN change journal to determine all the modifications made to a set of files. The part of the USN change journal that matters to us is the $USNJRNL•$J file found in the $Extend folder at the root of applicable NTFS volumes. This file is a sparse file which means that only non zero data is allocated and written to disk - from a practical point of view the relevance of this will become obvious in the next section of this post. The capability to create and maintain USN Change Journals exists in all versions of NTFS from version 3.0 onwards. This means that they can exist in all Windows versions from Windows 2000 onwards, however the functionality was only turned on by default in Vista and subsequent Windows versions.</p><p style="clear: both">You might be thinking by now - why from an evidential perspective does the USN Change Journal matter? A good question and in many cases with data in a live file system USN Change Journal entries might not assist. However it may be relevant to establish the latest event to occur to a file. The event is recorded by creating a reason code in each record within the journal. These reason codes are detailed in Lance's post and by Microsoft <a href="http://msdn.microsoft.com/en-us/library/cc232038(PROT.10).aspx">here</a>. Where I think the journal entries may be more useful is in establishing some information about a file that no longer exists in the live file system but is referenced elsewhere.<br /><br /><strong>Lance Mueller's Enscript</strong><br /><a href="http://www.forensickb.com/2008/09/enscript-to-parse-usnjrnl.html" target="_blank">Lance's script</a> is designed to parse a live $USNJRNL•$J file and output the parsed records into a CSV file. Like Seth Nazzaro I found that when I tried to run the Enscript Encase hung. This turned out not to be a problem with the script but a problem with how Encase presents sparse files. My $USNJRNL•$J file was recorded as being over 6GB in size. Only the last 32MB (or thereabouts) contained any data, the preceding data was a lot of zeroes -00 00 00 00 ad infinitum. Because the file is a sparse file the zeroed out portion of the file is not actually stored on disk - it is just presented virtually. However it appears that the script needed to parse through the almost 6GB of zeroes before it got to the juicy bits which gave the appearance of the script hanging (or resulting in Encase running out of memory). The solution to this was simple - copy out the non zero data into a file entitled $USNJRNL•$J. Create a folder named $Extend and place your extracted file into it. Drag the folder into a new Encase case as Single Files. Rerun the script which will then process the entries almost instantaneously. </p><p style="clear: both"><strong>Seth Nazzaro's Python Script</strong><br />Seth wrote <a href="http://code.google.com/p/parser-usnjrnl/" target="_blank">his script</a> because he had difficulty in running the Enscript -possibly for the reasons described above. I have described how to run the script in my <a href="http://forensicsfromthesausagefactory.blogspot.com/2010/07/python.html" target="_blank">earlier Python post</a>. The script is useful in validating results ascertained by other means and particularly for the comprehensive way it parses the reason codes (many record entries contain more than one reason code and the way they amalgamate together can be a bit confusing). The script also outputs to a CSV file.</p><p style="clear: both"><strong>Recovering USN Change Journal Records from unallocated</strong><br />Regular readers will know that I am particularly keen in recovering file system and other data from unallocated. I am pleased to see <a href="http://blogs.sans.org/computer-forensics/2010/05/04/timestamped-registry-ntfs-artifacts-unallocated-space/" target="_blank">I am not alone</a>. In many cases because of OS installations over the top of the OS where your evidence was created we have no choice but to recover evidence from unallocated. <br /><br /></p><p style="clear: both"><a href="http://lh3.ggpht.com/_QfcS6HZ5Sws/TFfMffGCG7I/AAAAAAAABGY/1259JtE16MU/s800/USN_records_in_ua.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUiS2Hego8lstb9jo2wAXmwopZ4ppvhtxVZk2dk2ObqiEGBvmSDQB_z5j3BdCLeNIq7ZNzW9A1tSwiVW0Pf5RwppAIBweDd-K_AvgG9gzZvIhUYrU_4wsh5ZeYn32Tc_N8Z2afcOmKN-zG/s800/USN_records_in_ua-thumb.png" height="318" align="left" width="500" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>It is possible to locate large numbers of deleted USN Change Journal Records in unallocated clusters. There is a clear structure to them</em>.<br /><br /><br /><br /><br /></p><p style="clear: both"><br />To carve these from unallocated I use my file carver of choice <a href="http://www.bladeforensics.com/" target="_blank">Blade</a>. I have created a Blade data recovery profile which recovered a very large number of records from my test data.</p><blockquote style="clear: both"><p> Profile Description: $UsnJrnl·$J records<br /> ModifiedDate: 2010-07-14 08:32:57<br /> Author: Richard Drinkwater<br /> Version: 1.7.10195<br /> Category: NTFS artefacts<br /> Extension: bin<br /> SectorBoundary: False<br /> HeaderSignature: ..\x00\x00\x02\x00\x00\x00<br /> HeaderIgnoreCase: False<br /> HasLandmark: True<br /> LandmarkSignature: \x00\x3c\x00<br /> LandmarkIgnoreCase: False<br /> LandmarkLocation: Static: Byte Offset<br /> LandmarkOffset: 57<br /> HasFooter: False<br /> Reverse: False<br /> FooterIgnoreCase: False<br /> FooterSignature: \x00<br /> BytesToEOF: 1<br /> MaxByteLength: 1024<br /> MinByteLength: 64<br /> HasLengthMarker: True<br /> UseNextFileSigAsEof: False<br /> LengthMarkerRelativeOffset: 0<br /> LengthMarkerSize: UInt32</p></blockquote><p style="clear: both">You may wish to be more discriminatory and carve records relating to just avi and lnk files for example. A small change to the Landmark Signature achieves this.</p><blockquote style="clear: both"><p> LandmarkSignature: \x00\x3c\x00[^\x2E]+\x2E\x00[al]\x00[vn]\x00[ik]</p></blockquote><p style="clear: both">The next step is to process the recovered records. Given we already have two separate scripts to do this all we have to do is to present the recovered records to the scripts in a form they recognise. This is achieved by concatenating the recovered records contained within the blade output folders</p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgDavPA4vs9E_oJuB2yznSbI9sRCSI2FjcTOwfga57lW0-Hg2iNaOG7ZRPoLhSBr3vvZxFnFRXim0XQVt6ewDhg7X83LQou_i8x6tRDuHkifFa2bFnydz3bBIY3TCHecQFt7upXdvjCz80D/s800/Blade_output_folders.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3UVq9BHbd3wT6rx4n4IeXF0P3mIgMQpvPeY0Wk8kJZhTIRf8lREn1qHNfX6K4M8t8UyCs0wlafZ_aWj4i4noZfbT-aNdf_k-8JUaJuljRASMPKISQGtkl_I_tEYOg3Fl-b_99soVV7eVM/s800/Blade_output_folders-thumb.png" height="391" align="left" width="343" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br style="clear: both" />This can be achieved at the command prompt, folder by folder <em><strong>> copy *.bin $USNJRNL•$J</strong></em>. However if you have recovered a very large number of records and have a considerable number of Blade output folders this can be a bit tedious. To assist with this John Douglas over at <a href="http://www.qccis.com/digital-forensics" target="_blank">QCC</a> wrote me a neat program to automate the concatenation within the Blade output folders (email me if you would like a copy). John's program Concat creates a concatenated file within each output folder in one go. Once you have the concatenated <em>$USNJRNL•$J </em>files you can then run either script against them. Please note the folder structure the enscript requires as referred to above.</p><p style="clear: both">Carving individual records in this fashion will result (at least in my test cases) in the recovery of a lot (possibly hundreds of thousands) of records. There will be considerable duplication. Excel 2007 or later will assist with the de-duplication within the scripts output.</p><p style="clear: both">Given the potentially large number of records that are recoverable I found it sensible to</p><ul style="clear: both"><li>run a restricted Blade Recovery profile for just the file types you are interested in (e.g. avi and lnk)<br /></li><li>Run John Douglas's concat.exe across Blades output<br /></li><li>In Windows 7 use the search facility to locate each concatenated <em>$USNJRNL•$J </em>file<br /></li><li>copy them all into one folder allowing Windows to rename the duplicates<br /></li><li>at the command prompt use a for loop to process them along the lines of<br /><strong>>for /L %a in (1,1,40) do python UsnJrnl-24NOV09.py -f "UsnJrnl</strong><em>•</em><strong>$J (%a)" output%a -t</strong><br />or<br /><strong>></strong><strong>for /L %a in (1,1,40) do python UsnJrnl-24NOV09.py -f "UsnJrnl</strong><em>•</em><strong>$J (%a)" -s >> output.tsv</strong><br /></li><li>or drag the concatenated files back into Encase as single files and process further with Lance's script.</li></ul><p style="clear: both"><strong>References</strong><br /><a href="http://www.opensource.apple.com/source/ntfs/ntfs-64/kext/ntfs_usnjrnl.h?txt" target="_blank">http://www.opensource.apple.com/source/ntfs/ntfs-64/kext/ntfs_usnjrnl.h?txt</a><br /><a href="http://www.microsoft.com/msj/0999/journal/journal.aspx" target="_blank">http://www.microsoft.com/msj/0999/journal/journal.aspx</a><br /><a href="http://technet.microsoft.com/en-us/library/cc976808.aspx " target="_blank">http://technet.microsoft.com/en-us/library/cc976808.aspx </a><br /><a href="http://wapedia.mobi/en/USN_Journal" target="_blank">http://wapedia.mobi/en/USN_Journal</a> <br /><a href="http://code.google.com/p/parser-usnjrnl/" target="_blank">http://code.google.com/p/parser-usnjrnl/</a><br /><a href="http://www.forensickb.com/2008/09/enscript-to-parse-usnjrnl.html" target="_blank">http://www.forensickb.com/2008/09/enscript-to-parse-usnjrnl.html</a> <br /><br /></p><p style="clear: both"></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com3tag:blogger.com,1999:blog-5057815281194312844.post-40797834602552540212010-07-23T13:41:00.000+01:002010-07-23T13:41:32.440+01:00Python<p style="clear: both">As regular readers will know here in the Sausage Factory our primary forensics tool is Encase. From time to time however we need to try out other tools to validate our results. Recently I wanted to utilise two python scripts widely discussed elsewhere and as a result had to figure out the mechanics of getting these scripts to run on a forensic workstation running Windows 7. I thought I'd share the process with you. Now some of you are highly geeky programmer types who write and run scripts for breakfast - if thats you turn away now. This blog post is in no way definitive and is intended for python newbies wishing to run python scripts in their forensicating but who until now didn't know how. </p><p style="clear: both">First off we need to install and configure Python</p><blockquote style="clear: both"><p><ul style="clear: both"><li>Download <a href="http://www.python.org/download/" target="_blank">Python</a> - I downloaded Python 2.7 Window X86-64 installer for my Windows 7 64 bit box<br /></li><li>Run the installer<br /></li><li>Right click on the <em>Computer icon</em>, select <em>properties</em>, select <em>Advanced system settings</em> and click on the <em>Environment Variables</em> button.<br /></li><li>In the System Variables pane you will have a variable entitled Path, select it and click on edit<br /></li><li>Add to the entries already there <em><strong>;C:\Python27 </strong>(assuming you installed Python 2.7 to the default location)</em></li></ul></p></blockquote><p style="clear: both">The two scripts I wanted to run were David Kovar's analyzeMFT and the $USNJRNL parser written by Seth Nazzaro. They are designed to parse MFTs and USN Change Journals respectively which can be copied out of an image or made available via VFS or PDE. More about analyzeMFT can be found at the <a href="http://integriography.wordpress.com/?s=analyzeMFT" target="_blank">author's blog</a>. Detailing how I ran these scripts will give a clear indication of how to run these, and many other python scripts, and utilise their output.</p><p style="clear: both"><strong>analyzeMFT</strong><br />Download script by visiting <a href="http://www.integriography.com/" target="_blank">http://www.integriography.com/ </a> and right clicking on the <em>Downloaded Here</em> link in the Downloads section (for the source code) and saving the download as a text file. Once downloaded change the file extension to <em><strong>.py.</strong><br /><br /></em>Save it somewhere and then run IDLE (installed with Python) and open the analyzeMFT.py script. Locate the words <strong>noGUI = False</strong> and edit to read <strong>noGUI = True</strong> and save.</p><p style="clear: both">To run </p><ul style="clear: both"><li>open command prompt<br /></li><li>at prompt type <strong>Python C:\Path_to_the_script\analyzeMFT.py -f U:\Path_to_your_extracted_or_mounted_MFT\$MFT -o $MFT_parsed</strong><br /></li><li>The above command runs the script against your extracted or mounted $MFT and outputs the results to a file $MFT_parsed<br /></li><li>Open $MFT_parsed using the text import wizard in Excel selecting the text format for each column.<br /></li></ul><p style="clear: both">Thanks to David Kovar for making this script available.</p><p style="clear: both"><strong>$USNJRNL•$J Parser</strong><br />This script can be downloaded at <a href="http://code.google.com/p/parser-usnjrnl/">http://code.google.com/p/parser-usnjrnl/</a>. </p><p style="clear: both">To run</p><p style="clear: both"><ul style="clear: both"><li>open command prompt<br /></li><li> at prompt type <strong>Python C:\Path_to_the_script\UsnJrnl.py </strong><strong>-f U:\Path_to_your_extracted_or_mounted_<strong>USNJRNL•$J</strong>\<strong><strong>USNJRNL•$</strong></strong> -o Output_file -c</strong><br /></li><li>The above command runs the script against your extracted or mounted $USNJRNL•$J and outputs the results to Output_file.csv<br /></li></ul><br /><strong>Notes</strong><br />Typing at the command prompt <strong>Python path_to_script.py </strong>wil give some help about a scripts options. For example <strong>Python UsnJrnl.py</strong> results in the output</p><blockquote style="clear: both"><p style="clear: both">Usage: UsnJrnl.py [options]<br />Options:<br /> -h, --help show this help message and exit<br /> -f INFILENAME, --infile=INFILENAME <br /> input file name<br /> -o OUTFILENAME, --outfile=OUTFILENAME<br /> output file name (no extension)<br /> -c, --csv create Comma-Separated Values Output File<br /> -t, --tsv create Tab-Separated Values Output File<br /> -s, --std write to stdout</p></blockquote><p style="clear: both">I have installed Python 2.7. There are other (and later) versions available including some that are not completely open source. It is also possible to install Python modules to provide a GUI. I have not installed these - takes the fun out of running scripts!<br /><br /></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com6tag:blogger.com,1999:blog-5057815281194312844.post-72775851411441888042010-07-19T22:32:00.000+01:002010-08-06T14:20:52.946+01:00Gatherer Transaction Log Files - a Windows Search artefact<p style="clear: both">A recurring theme in many examinations is the prevalence of evidence in unallocated clusters. Reinstallation of the OS is often to blame and a recent case where XP was installed on a drive where the previous OS was Vista further complicated matters. All relevant data had been created during Vista's reign and the challenge was to determine what files and folders existed under this OS. The Encase Recover Folders feature assisted to an extent as did <a href="http://support.digital-detective.co.uk/KB/Default.aspx?ID=KB80038" target="_blank">Digital Detective's Hstex 3</a>. Loading the output of Hstex 3 into NetAnalysis allowed me to identify the download of a number of suspect files and some local file access to files within the Downloads folder.</p><p style="clear: both">The next step was to carry out a keyword search utilising the suspect file names as keywords. This is always a good technique and results in the identification of useful evidence in a variety of artefacts (e.g. index.dats, link files, registry entries, NTFS file system artefacts et al) but because in this case every thing was unallocated identifying all the artefacts was a little tricky. A considerable number of the search hits were clearly within some structured data but the data was not an artefact I was familiar with.</p><p style="clear: both"></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1qECp6nGGsq20tyUuPVMr8369RXD5mV09Z8vvcL1oGh_NGgl49HwXgs5Ye-o-g7Zc_IDGp7YaD4Z4HNsX9IcuH5zyXa7oZjc6wzV7W0bpNT8HDYZ-KUXa5IiJ7SE_UP3KoLE5c-27b3BU/s800/Gather_Log_Entries_in_UA.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiyakDvMPoB75gSIfRoCYim0xSzKdE17Y-tbtc1CWl01f59fbN2Xnusyy-KnlenmtZkY0UnOklE5fRmzqv1Vj1UFEuwf-ZsbbaVM8ena_kFiLr7MeCNELkwrZWA93EIS43UQMoJVRaK1-l2/s800/Gather_Log_Entries_in_UA-thumb.png" height="299" align="left" width="380" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>I have highlighted Record Entry Headers to draw attention to the structured nature of the data. This screen shot is of test data where the file names/path are stored as unicode as opposed to ASCII in the case I was investigating.</em></p><p style="clear: both">A bit of googling led me to page 42 of <em>Forensic Implications of Windows Vista - Barrie Stewart </em>which identified the structured data I had located as being part of <em>Gatherer Transaction Log </em>files created by the search indexer process of <em>Windows Search</em>. These files have a filename in the format <em>SystemIndex.NtfyX.gthr</em> where the X is replaced by a decimal number and on a live Vista system can be found at the path <em><br /></em></p><p style="clear: both"><em>C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Projects\SystemIndex\</em></p><p style="clear: both"><br />These files have the words <em>Microsoft Search Gatherer Transaction Log. Format Version 4.9</em> as a file header. The files are a transaction log of entries committed to the Windows search database indexing queues. The SearchIndexer process monitors the <a href="http://msdn.microsoft.com/en-us/library/aa363798(v=VS.85).aspx" target="_blank">USN Change Journal</a> which is part of the NTFS file system used to track changes to a volume. When a change is detected (by the creation of a new file for example) the SearchIndexer is notified and the file (providing it is in an indexable location - mainly User folders) is added to the queue to be indexed. The USN Change Journal is also something that may contain evidentially useful information and I will look at it in more depth in <a href="http://forensicsfromthesausagefactory.blogspot.com/2010/08/usn-change-journal.html" target="_blank">a later blog post</a>.</p><p style="clear: both">Sometimes artefacts are only of academic interest but it was fairly apparent that this data could have some evidential value. Each file or folder has a record entry; parts of which had been deconstructed by <em>Stewart. </em>I was able to identify two additional pieces of information within each record - the length of the Filename block and a value that is possibly a sequence or index number or used to denote priority. I also observed some variations in some parts of the record that had been constant in <em>Stewart's</em> test data.</p><blockquote style="clear: both"><p><ul style="clear: both"><li>Record Header 0x4D444D44 [4 bytes]<br /></li><li>Unknown variable data [12 bytes]</li><li>FILETIME Entry [8 bytes] <br /></li><li>FILETIME Entry [8 bytes] or a value of 0x[0100]00000000000000</li><li>Unknown variable data [12 bytes]</li><li>Length of file path following plus 1 byte (or plus 2 bytes if file path stored as unicode) [4 bytes] stored as 32 bit integer</li><li>Name and fullpath of file/folder (ASCII or Unicode -version dependant) [variable length]<br /></li><li>0x000000000000000000FFFFFFFF [13 bytes]<br /></li><li>FILETIME Entry [8 bytes] or a value of 0x[0100]00000000000000<br /></li><li>0xFFFFFFFF [4 bytes]<br /></li><li>FILETIME Entry [8 bytes] or a value of 0x[0100]00000000000000<br /></li><li>Unknown variable data [4 bytes]<br /></li><li>Sequence or index number? [1 byte] stored as 8 bit integer<br /></li><li>Unknown variable data [15 bytes]<br /></li><li>FILETIME Entry [8 bytes] or a value of 0x[0100]00000000000000<br /></li><li>FILETIME Entry [8 bytes] or a value of 0x[0100]00000000000000<br /></li><li>Unknown variable data [20 bytes]</li></ul></p></blockquote><p style="clear: both">Microsoft do not seem to have publicly documented the record structure. To establish how useful this data can be I came to the conclusion that I needed to recover all of these records from unallocated. I needed an enscript and Oliver Smith over at <a href="http://www.cy4or.co.uk" target="_blank">Cy4or</a> kindly wrote one for me. I wanted the enscript to parse out the file and path information, sequence or index number, the six time stamps and a hex representation of each unknown range of data into a spreadsheet. The script searches for and parses individual records (from the live systemindex file and unallocated) as opposed to entire files. I was astonished at just how much information the script parsed out - email me if you want a copy. Setting the spreadsheet to use a fixed width font (Courier New) lines up the extracted hex very well should anyone want to reverse engineer these records further. As it stands the file paths and timestamps can provide some useful evidential information, particularly when the recovered records have been recovered from unallocated clusters and relate to a file system older than the current one.</p><p style="clear: both"><strong>Timestamps</strong><br />Obviously once you have run this enscript or manually examined the records the first question that arises is what are the timestamps. Establishing this has not been as easy as it could be and hopefully a little bit of crowd sourcing will sort this out for all of us. Post a comment if you can help in this regard. One approach is to use the hex 64 bit filetime value as a keyword and see where you get hits. Hits in another timestamp indicates that the timestamp is the same down to the nanosecond. Carrying out this process will result in hits in OS system files and fragments of them. I have found on the limited test data set I have used that Timestamp 3 matched the <a href="http://kcrazy.timeegg.com/Favorites/ntfsdoc.htm#id4752813" target="_blank">File Modified (File Altered)</a> date within MFT for the file concerned and the timestamp for the same file in the USN Change Journal. The timestamp in the USN Change Journal record is the absolute system time that the change journal event was logged <a href="http://msdn.microsoft.com/en-us/library/cc232038%28PROT.10%29.aspx" target="_blank">(1)</a>. It is worth reminding readers who are Encase users that Encase uses different terminology for the time stamps within the MFT - <a href="http://whereismydata.wordpress.com/2009/04/10/forensics-what-does-entry-modified-mean-in-encase/" target="_blank">file modified is referred to as Last Written</a>. I think it likely that timestamps 1 and 2 are linked to the indexing function (e.g. time submitted for indexing) given the journalling nature of the file but can not either prove this by testing or confirm this within Microsoft documentation. I can say that in testing sorting on Timestamp 1 gave a clear timeline of the file system activity I had provoked within User accessible folders.</p><p style="clear: both"></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqEVyxiJBf9mlxf3Ttl4QEkL4t5FsVGrcorOq2TLH3SMnhiSfm67DQSLv3mbSdaLuZyJ6Tp1SxXfQUYoitd6P4oHlzCsIILBOffstIWztgqnV_qpqPO_oNYVTuby1b_kXOV6em54TPVBGJ/s800/example_spreadsheet.jpg" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimvgGydJ196aDIj2bfBFDjflUVJnvEs0J_rTrOg6mMuotUOcFu8e5SDTweDdY4b0OtVExysl1cG2REVbVnp-zpkcYBTtmI21xzNzMqw4yZjev_XIk3RRlHuDs9uo4sBocxd-qznOm32uFL/s800/example_spreadsheet-thumb.jpg" height="229" align="left" width="500" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br style="clear: both" /><br /><em>Example CSV output of Enscript (click to enlarge)</em><br /><br /></p><p style="clear: both"><strong>References</strong><br /><a href="http://www.microsoft.com/downloads/details.aspx?FamilyID=F8E87C7D-9404-4914-92AE-DDE09389A64E&displaylang=en" target="_blank">Good citizenship when developing background services for Windows Vista - Microsoft</a><br /><a href="http://whereismydata.files.wordpress.com/2009/09/forensic-implications-of-windows-vista.pdf" target="_blank">Forensic Implications of Windows Vista - Barrie Stewart</a><br />Forensic Artefacts Present in Microsoft Windows Desktop Search - John Douglas MSc Thesis<br /><a href="http://msdn.microsoft.com/en-us/library/cc678933(VS.85).aspx">Indexing Process in Windows Search - Microsoft MSDN</a><br /><a href="http://msdn.microsoft.com/en-us/library/cc232038%28PROT.10%29.aspx" target="_blank">(1) http://msdn.microsoft.com/en-us/library/cc232038%28PROT.10%29.aspx</a></p><p style="clear: both"></p><p style="clear: both"></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com6tag:blogger.com,1999:blog-5057815281194312844.post-39188050519006463862010-06-28T21:56:00.000+01:002010-06-28T21:56:47.824+01:00Safari Internet History round up<p style="clear: both">The last few posts all concern the recovery of internet history created by the Safari browser. I like to think of internet history in the wider sense and consider any artefact that demonstrates that a user visited a URL at a particular time.</p><p style="clear: both"><a href="http://forensicsfromthesausagefactory.blogspot.com/2010/06/recovering-safari-browser-history-from.html" target="_blank">Recovering Safari browser history from unallocated</a> deals with history.<br /><a href="http://forensicsfromthesausagefactory.blogspot.com/2010/06/safari-browser-cache-examination-of.html" target="_blank">Safari browser cache -examination of Cache.db</a> deals with the cache.<br /><a href="http://forensicsfromthesausagefactory.blogspot.com/2010/06/never-mind-cookies-lets-carve-crumbs.html" target="_blank">Never mind the cookies lets carve the crumbs - Safari Cookie stuff</a> looks at Cookies.<br /><a href="http://forensicsfromthesausagefactory.blogspot.com/2010/06/safari-history-spotlight-webhistory.html" target="_blank">Safari History - spotlight webhistory artefacts</a> examines Spotlight snapshots of web pages accessed with Safari.</p><p style="clear: both">To round things up I will briefly list some other files or locations that may provide internet history created by the Safari browser (the ~ denotes the path is within a user profile)</p><blockquote style="clear: both"><p><em>~/Library/Safari/LastSession.plist</em><br />Used to store details of the last browser session allowing a user to select <em>Reopen All Windows from Last Session </em>from the safari history menu.<em><br /></em></p></blockquote><blockquote style="clear: both"><p><em>~/Library/Safari/WebpageIcons.db<br />~/Library/Safari/Icons.db</em><br />Used to store the associations between websites and their favicons.</p></blockquote><blockquote style="clear: both"><p>~<em>/Library/Safari/TopSites.plist<br />~/Library/PubSub/Feeds/............... .xml<br />~/Library/Caches/com.apple.Safari/Webpage Previews</em><br /><a href="http://www.apple.com/safari/includes/overlay_features1.html#gallery-features1" target="_blank">TopSites is a gallery</a> of recently visited web sites. The binary <em>TopSites.plist</em> details the websites featured in this gallery. The image representing each webpage is stored within the <em>Webpage Previews</em> folder. This folder also stores any <em>Quicklook</em> representation of a webpage, for example when managing <em>Bookmarks</em> or reviewing <em>History</em>. File names of files in the Webpage Previews folder are the MD5 of the associated URL. Safari monitors whether a page has altered since it was last viewed and appends a blue star to the TopSites view for those sites that have. The xml files in <em>PubSub/Feeds</em> are connected with the monitoring.</p></blockquote><blockquote style="clear: both"><p><em>~/Library/Safari/Downloads.plist</em><br />An xml plist the contents of which are self explanatory.<br /><em>~/Library/Caches/Metadata/Safari/History/.tracked filenames.plist</em><br />A binary plist that <em>may</em> be connected to Safari spotlight web history artefacts.</p></blockquote><p style="clear: both"><br /><br /></p><p style="clear: both"></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-20155062048531497792010-06-22T09:50:00.000+01:002010-06-22T09:50:20.554+01:00Never mind the cookies lets carve the crumbs - Safari Cookie stuff<p style="clear: both">Safari versions 3, 4 and 5 amalgamates Cookie data into one large file <em>Cookies.plist</em> stored at the path <em>~/Library/Cookies. </em>This plist is an XML plist. The Encase Internet History search will parse these files and when set to Comprehensive search will find fragments of them in unallocated. However perhaps due to its lack of granularity this search takes forever to run across a Mac and in my experience often fails to complete</p><p style="clear: both">As is becoming a recurring theme with my Safari examinations I have turned to <a href="http://www.bladeforensics.com/" target="_blank">Blade</a> to carve out Safari Cookie data from unallocated. The Cookie.plist consists of an array of dictionary objects. </p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfZNRLbMcl7p3Vw4V2OoYkc77gGUYFytyYYj69AwdR_Lpq7y8tcSKi79O0F2qSiuGanY3rDI1kb5RMkSAJT03hSA_iMQIzR_rTjEpje2B-wucH5yM-T0zAhYNtb1cuBNbef_XtUiACVTqF/s800/Screen_shot_2010-06-21_at_14.22.20.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_DoMdyyBk8CvpaPG0W6XDGq3jXtsmHQ6oh7FEU1b1MM3okhWZ1jCV36GOkWS0mYvDzOtiCRjQNssTTVx_2GlAY527MAVtqcq0nQnQJ_vEhZQlrLmORKnReMx6vM-kBq2KAVSUl0uu-swW/s800/Screen_shot_2010-06-21_at_14-thumb.22.20.png" height="231" align="left" width="245" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br /><em>Using Apple's Property List Editor it can be seen that this Cookie.plist has an array of 7074 Dictionary objects. Each Dictionary object is a Cookie in its own right.</em><br /><br /><br /><br /></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBpmRbbN_dazIX5zLDBigpti7dvMo-7XumUXtednlLjD-hNHFyq7q0_FFXdoC7W7-OXGt39QdiH_0JIZ_JumN91CRFizKvFoe67AymkcYLVmPDx5Aqq_v7vtYfOjI1rrKfiZgCRzoHf-oo/s800/Screen_shot_2010-06-21_at_14.29.1.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTjiG2qvSDdGOW51ch9ITJO84efwBloEfZXH6W5A7wlDrr2_otcNpcoI5ca0i45cYPXEkLlt4i9kK3t_2p5tkkNQOUcsWIDnn_iEg98uTRz4xeMy2mS2ZxZzsDr6bHspY5avDWnOm5O15S/s800/Screen_shot_2010-06-21_at_14-thumb.29.1.png" height="348" align="left" width="379" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br /><em>Looking at the underlying XML you can see how each dictionary object is structured.<br /></em><br /><br /><br /><br /><br /><br /></p><p style="clear: both">In creating a recovery profile I considered whether I wanted to carve out deleted cookie plists in their entirety or whether I should carve each dictionary object separately. <em>These dictionary objects are fragments of the cookie.plist - hence the crumb reference in the title -after all fragments of cookies are clearly crumbs.</em> I decided that it would be a more thorough search if I carved for the dictionary objects themselves and the following Blade data recovery profile did the business (this data is extracted from Blade's audit log -another neat feature).</p><blockquote style="clear: both"><p style="clear: both"> Profile Description: Safari Cookie records<br /> ModifiedDate: 2010-06-17 06:33:30<br /> Author: Richard Drinkwater<br /> Version: 1.3.10168<br /> Category: Safari artefacts<br /> Extension: plist<br /> SectorBoundary: False<br /> HeaderSignature: \x3C\x64\x69\x63\x74\x3E\x0A\x09\x09\x3C\x6B\x65\x79\x3E\x43\x72\x65\x61\x74\x65\x64\x3C\x2F\x6B\x65\x79\x3E\x0A\x09\x09\x3C\x72\x65\x61\x6C\x3E<br /> HeaderIgnoreCase: False<br /> HasLandmark: True<br /> LandmarkSignature: <key>Expires</key><br /> LandmarkIgnoreCase: False<br /> LandmarkLocation: Floating<br /> LandmarkOffset: 0<br /> HasFooter: True<br /> Reverse: False<br /> FooterIgnoreCase: False<br /> FooterSignature: \x3C\x2F\x73\x74\x72\x69\x6E\x67\x3E\x0A\x09\x3C\x2F\x64\x69\x63\x74\x3E\x0A<br /> BytesToEOF: 19<br /> MaxByteLength: 9728<br /> MinByteLength: 200<br /> HasLengthMarker: False<br /> UseNextFileSigAsEof: True<br /> LengthMarkerRelativeOffset: 0<br /> LengthMarkerSize: UInt16</p></blockquote><p style="clear: both"><strong>Processing the Carved Files</strong></p><p style="clear: both">If your case is anything like mine you will carve out thousands and thousands of individual cookies (or at least the cookie data represented in XML). There are a number of options to process this data further.</p><blockquote style="clear: both"><p style="clear: both"><strong>Option 1</strong><br /><ul style="clear: both"><li>Drag output into Encase as single files. </li><li>Run Encase Comprehensive Internet History search.</li><li>View results on records tab.</li></ul></p><p style="clear: both">There are two issues with this method. Firstly Encase does not parse the Cookie created date which is stored as an CFAbsolute timestamp. Secondly there is the issue of duplicates. You will have thousands and thousands of duplicates. These can be managed by hashing the carved files. I would also recommend running the data recovery profile over any live cookie.plists, loading the output into Encase as single files, hashing the output and then creating a hash set. This hash set will allow you to spot additional cookies over and above those in the live cookie plists in any cookies carved from unallocated.</p><p style="clear: both"><strong>Option 2</strong><br /><ul style="clear: both"><li>Concatenate the contents of each output folder by navigating to the folder at the command prompt and executing the command <strong>copy *.plist combined.plist.</strong></li><li>With a text editor add the plist header and array tag at the beginning of <strong>combined.plist </strong>and the closing plist and array tags at the end.</li><li>Make sure the formatting of <strong>combined.plist</strong> looks OK with a text editor.</li><li>Process <strong>combined.plist</strong> with <a href="http://jafat.sourceforge.net/files.html" target="_blank">Jake Cunningham's safari cookie plist parser</a>. <br /></li><li>The utility is run from the command prompt using a command in the form<br /><strong>></strong><em>[path to Safari_cookies.exe] [path to combined.plist] > cookies.txt</em><br /></li><li>This parses the plist into the file <em>cookies.txt</em><br /></li><li>This text file may contain many thousands of Cookies. Ideally it would be nicer to port this data into a spreadsheet. To do this I (<em>there is probably a far more elegant way to do this BTW</em>) open <em>cookies.txt</em> in a hex editor (PSPad Hex) and delete all the carriage returns 0D0A. I then find the string <em>Path</em> [50617468] and replace it with 0D0A7C50617468 -in other words preface path with a carriage return and the pipe symbol |. I then find and replace the strings <em>Domain, Name, Created, Expires</em> and <em>Value</em> and replace each in turn with the same string prefaced with | (e.g. <em>|Domain, |Name</em> etc. etc.)<br /></li><li>I then use Excel's text import wizard to import the edited <em>cookies.txt</em> setting the delimiter to the pipe symbol | only.<br /></li><li>This results in each row relating to one cookie. You can then utilise Excel's very powerful duplicate removal tool.</li></ul>Both the Mac and Windows versions work OK and the utility converts the CFAbsolute formatted cookie created timestamp.<br /><br /></p></blockquote><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-8041814262119006132010-06-15T10:59:00.000+01:002010-06-15T10:59:50.396+01:00Safari History - spotlight webhistory artefacts<p style="clear: both">June is Safari month here in the Sausage Factory and this post is the third in the series. Just imagine having an observation point in the house across the road from your suspect. When the suspect surfs the internet the man in the OP (with the help of a good pair of binoculars) makes notes of what he reads on screen (OK.. he may use a long lens instead of binoculars and take photos but bear with me). Essentially this is exactly what Spotlight does when a user utilises the Safari web browser (versions 3,4 and 5) to view web pages - it writes the URL, Web Page Title and all the text content in the web page into a file. </p><blockquote style="clear: both"><p><ul style="clear: both"><li>These files filenames are in the format <em>URL.webhistory</em><br /></li><li>Their internal structure is that of a binary plist with three strings to each record Full Page Text, Name and URL</li><li>They are stored at the path ~/Library/Caches/Metadata/Safari/History<br /></li><li>The file created date of these files represents the time that the URL was first visited (since History was last cleared)<br /></li><li>The file modified date represents the time that the URL was last visited<br /></li></ul></p></blockquote><p style="clear: both">It can be seen that it is possible to deduce information from these files that amounts to internet history and therefore it it may be appropriate to consider this data along with records extracted from history.plist and cache.db files.</p><p style="clear: both"><strong>Recovery from Unallocated</strong><br />These files are deleted when a user clears Safari history. However it is possible to recover these files from unallocated. Using my file carver of choice - <a href="http://www.bladeforensics.com/" target="_blank">Digital Detective's Blade</a> I wrote an appropriate Data Recovery Profile (which I will happily share with you upon request)<br /><br /><br /></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmeZSFge7Q_U5LFquLgwZqWuLlSlx_s4BzGqLXqg7L0uCaouRg3uVScQUrOQYnNP4eZH8eB71WTe1Vi9guc0CzPSdV5EALAw6LtAwWH01Np_tobpnenpqXED9Ato5mO5deqv2G4UR8VzuZ/s800/webhistory_Recovery_profile_screenshot.png" class="image-link"><img class="linked-to-original" src="http://lh3.ggpht.com/_QfcS6HZ5Sws/TBY-8GnoS6I/AAAAAAAAA_g/_LL5H3nceVI/s800/webhistory_Recovery_profile_screenshot-thumb.png" height="324" align="left" width="380" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br style="clear: both" /><em>Click on image for larger version</em><br /><br /></p><p style="clear: both">Running this profile resulted in the recovery of over ten thousand files. I then added the recovered files into Encase as single files. I noticed that a small percentage of these files had the text content stored as ascii and not unicode text. I am at this stage not sure why.</p><p style="clear: both"><strong>Investigation of Live and Recovered Spotlight Webhistory Files using Encase</strong><br />If you review these files using Encase you will see in the View (bottom) pane the relevant data -the URL is at the start of the file, followed by the text in unicode and then the webpage title near the end of the file. If the content is relevant reporting on it is a pain -potentially three sweeping bookmarks are required using two different text styles. The unicode text sweeping bookmark is also likely to be truncated due its length. Therefore reviewing any number of these files this way is not a good plan.</p><p style="clear: both">The eagle eyed amongst you will have observed that in my Blade Data Recovery Profile I gave the recovered files a plist file extension (as opposed to a webhistory file extension). This because these files have a binary plist structure and I use Simon Key's binary <a href="https://support.guidancesoftware.com/forum/downloads.php?do=file&id=865" target="_blank">Plist Parser v3.5</a> enscript to parse them. This excellent enscript allows the option to create a logical evidence file which creates a file for each plist name/value pair. I run the enscript with this option, add the logical evidence file back into my case and the review the contents with just a unicode text style selected and bookmark as appropriate. This method is much quicker and removes the need to mess about with unicode formatting. It also makes keyword searching easier. For example to view all URLs green plate (set include) your logical evidence file, apply a sort to the name column in the table pane, scroll down to cause each URL to appear in turn in the view pane. Use a similar method for the Full Page Text and Name items.</p><p style="clear: both"><a href="http://lh6.ggpht.com/_QfcS6HZ5Sws/TBY8ydwS_aI/AAAAAAAAA-k/eA_e71tQGm0/s800/Encase_plist_parser_l01.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg0fc1gx2MnVTCyYKzR8LVc05VDnziS8Abfcofr0oCeMxOJ99rxjE8C7T2iiCIILzbHGYiaNnu0ovcNwmY3skjaFXcvmrxKXWMPqPUZy9JfOL1MMCeYU2rM1o6ExIdHip6sKXinoorCernU/s800/Encase_plist_parser_l01-thumb.png" height="393" align="left" width="380" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>Click on image for larger version</em></p><p style="clear: both"><br /><br /><strong>Miscellaneous Information in relation to the webhistory file format</strong><br />Prior to considering the Plist Parser enscript to parse these files I briefly looked at its format with a view to tempting some programming friends to write me a parser. I established that</p><ul style="clear: both"><li>The file is a binary plist. I do not want to too far into the intricacies of how these plists are assembled. We are interested in objects within the object table. Binary plists use marker bytes to indicate object type and size. The objects we are interested in are strings, either ASCII or unicode. Looking at <a href="http://opensource.apple.com/source/CF/CF-550/CFBinaryPList.c" target="_blank">Apple's release of the binary plist format</a> (scroll about a fifth of the way down the page) it can be seen that the Object Format Marker byte for ASCII strings found in this file is in binary 01011111, followed by an integer count byte. In hex these marker bytes as seen in this file are 5Fh 10h. The Object Format Marker byte for unicode strings found in this file is in binary 01101111, followed by an integer count byte. In hex these marker bytes as seen in this file are 6Fh 11h.</li><li>The byte immediately prior to the URL (generally starting http) and after the marker 5Fh 10h decoded as an 8 bit integer denotes the length of the URL. However if the URL is longer than 255 bytes the marker will be 5Fh 11h indicating the following two bytes are used to store the length decoded as 16 bit big endian</li><li>Following the URL there is a marker 6Fh 11h - the next two bytes decoded 16 bit big endian is the number of characters of text extracted from the web page - multiply by 2 to calculate the length of the unicode text element of the record<br /></li><li>Following the unicode text element is a marker 5Fh 10h -the next byte immediately prior to the webpage title decoded as an 8 bit integer denotes the length of the webpage title</li><li>the last four bytes of the file formatted 32 bit big endian is the record size (detailing the number of bytes from the start of the URL to the end of the fifth byte from the end of the file)</li></ul><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh2vxmHs3BLk8Pe-DupNS4JofzXlN5XYGhxfvQRWQADqlgFmPdQEcKK1dj1tFmCs3Na19L3tM1oWKU-v_-p_cj2WK4PpLifVd3OoFsY2qtiTfna3k9N0ppSTf6o4VgvlcXRUhXh7cQA_wnI/s800/webhistory_file_structure.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEia7S3D-5FWWbRlchoVvJycO8G-iLNY5NNkKxLgmjdxyldB552oVDtOsps7qEJuBMZIzWLlF7FeoP_fDD7leGWdIu9FqF88JzRS4hRocZfo8zUQ9J5q2arTFtEKhwSew8O7Ml-0BTQJmZLW/s800/webhistory_file_structure-thumb.png" height="498" align="left" width="380" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>Example file format</em><em><br /></em></p><p style="clear: both"><em>Click on image for larger version</em><br /><br /></p><p style="clear: both"><strong>References</strong><br />http://opensource.apple.com/source/CF/CF-550/CFBinaryPList.c<br />http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/PropertyLists/AboutPropertyLists/AboutPropertyLists.html#//apple_ref/doc/uid/10000048i-CH3-SW2</p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-91654809211408783752010-06-08T19:06:00.000+01:002010-06-12T06:50:37.637+01:00Safari browser cache - examination of Cache.db<p style="clear: both">Following on from <a href="http://forensicsfromthesausagefactory.blogspot.com/2010/06/recovering-safari-browser-history-from.html" target="_blank">my post about Safari browser history</a> I want to touch upon Safari cache. My suspect is running Mac OSX 10.5.6 Leopard and Safari 3.2.1. This version stores browser cache in an sqlite3 database ~/Users/User_Name<user_name>/Library/Caches/com.apple.Safari/Cache.db. Earlier versions of Version 3 and Version 1 and 2 store cache in a different format, and/or a different place. The <a href="http://insidethecore.com/Show%20Notes/show_notes.html" target="_blank">Episode 3 Shownotes </a>of the Inside the Core Podcast cover this succinctly so I will not repeat it here but FWIW I have cached Safari artefacts in all three forms on the box I have examined. Currently Netanalysis and Encase do not parse the Safari Cache.db file so another method is required. <br /></user_name></p><p style="clear: both"><strong>Safari Cache.db basics</strong><br />What follows I believe relates to versions 3, 4 and 5 of Safari running in Mac OSX.<br />The file contains lots of information including the cached data, requesting URL and timestamps. The file is a Sqlite3 database file which has become a popular format to store cached browser data. The cache.db database contains four tables. For the purposes of this post think of each table as a spreadsheet with column headers (field names) and rows beneath representing individual records.<br />Two tables are of particular interest:</p><ul style="clear: both"><li><strong>cfurl_cache_blob_data</strong></li><li><strong>cfurl_cache_response</strong><br /></li></ul><blockquote style="clear: both"><p><strong>cfurl_cache_blob_data </strong>contains one very notable field and a number of slightly less useful ones. The notable field is <em>receiver_data </em>which is used to store the cached item itself (e.g. cached jpgs, gifs, pngs, html et al ) as a BLOB. A BLOB is a <strong>B</strong>inary <strong>L</strong>arge <strong>OB</strong>ject. Two other fields <em>request_object</em> and <em>response_object </em>contain information relating to the http request/response cycle also stored as a BLOB which when examined further are in fact xml plists. The <em>entry_ID</em> field is the primary key in this table which will allow us to relate the data in this table to data stored in other tables.<br /></p></blockquote><blockquote style="clear: both"><p><strong>cfurl_cache_response </strong>contains two notable fields - <em>request_key </em>and <em>time_stamp</em>. The <em>request_key</em> field is used to contain the URL of the cached item. The <em>time_stamp</em> field is used to store the time (UTC) the item was cached. The <em>entry_ID</em> field is the primary key in this table which will allow us to relate the data in this table to data stored in cfurl_cache_blob_data.<br /></p></blockquote><blockquote style="clear: both"><p>In a nutshell <strong>cfurl_cache_blob_data </strong>contains the cached item and <strong>cfurl_cache_response </strong>contains metadata about the cached item.<br /></p></blockquote><p style="clear: both"><strong>Safari cache.db examination methods</strong><br />I would like to share three different methods using SQL queries and a few different tools.</p><blockquote style="clear: both"><p>Safari cache.db examination methods - contents <em>quick and dirty</em> <br />Safari cache.db examination methods - metadata <em>quick and dirty</em><br />Safari cache.db examination methods - contents and metadata</p></blockquote><p style="clear: both"><strong>Safari cache.db examination methods - contents </strong><em><strong>quick and dirty</strong></em><br />Depending on what you wish to achieve there are a number of different methods you can adopt. As regular readers will know I work on many IPOC cases. If all you want to do is quickly review the contents of cache.db (as opposed to the associated meta data) I can not recommend any application more highly than <a href="http://echoone.com/filejuicer/" target="_blank">File Juicer</a>. This application runs on the Mac platform (which I know is a gotcha for some) and parses out all cached items into a neat folder structure. </p><p style="clear: both"></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiAamq0qhye_XI9x5ElipiCgHS1ISLH9xuCSb-NEsSZ_4-zbrILn_U9zRE04481iHfTfMjk8km3i98KrKO6wOp7Atz3DGVqrbr9vUShEfDwBiXpzeM5YtTCCjXmkk4kD-PcYJDtPCwH3NGa/s800/Screen_shot_2010-06-08_at_11.08.56.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1rVi673Hv780OJ1wtmyMcYiTwoeOcuQvv7Ffduojrm8Ww0tqMk1Q3-sANCxywOUaWyZga_yqBs3StFEn6iZfeuWSGp7bLCbOp6mr8PXnZ1gvdYUaIyplX5CbSSSzd9HsjYKewB9e6xQdp/s800/Screen_shot_2010-06-08_at_11-thumb.08.56.png" height="287" width="194" style=" text-align: center; display: block; margin: 0 auto 10px;" /></a>I drag the File Juicer output folders into Encase as single files and examine the contents further there. File Juicer is not a forensic tool <em>per se</em> but the developer has at <a href="http://echoone.com/filejuicer/forensics" target="_blank">least considered the possibility</a> that it may be used as such. If using a Mac is not an option a Windows app <a href="http://www.sqlimageviewer.com/" target="_blank">SQL Image Viewer</a> may suffice (with the caveat that I have not actually tested this app).</p><p style="clear: both"><strong>Safari cache.db examination methods - metadata quick and dirty</strong><br />Sometimes overlooked is the fact that most caches contain internet history in the form of urls relating to the cached item. The cfurl_cache_response table contains two fields - request_key and time_stamp containing useful metadata. We can use an SQL query to parse data out of these fields. I use (for variety more than anything else) two different tools (i.e. one or the other) to carry out a quick review of meta data.</p><blockquote style="clear: both"><p>Method A using Sqlite3 itself (<a href="http://www.sqlite.org/download.html" target="_blank">http://www.sqlite.org/download.html</a> scroll down to the Precompiled Binaries for Windows section) <br /><ul style="clear: both"><li>extract your cache.db file into a folder<br /></li><li>copy sqlite3.exe into the same folder [to cut down on typing paths etc.]<br /></li><li>launch a command prompt and navigate to your chosen folder<br /></li><li>Type <em><strong>sqlite3 cache.db</strong></em><br /></li><li>then at the <em>sqlite</em> prompt type <strong><em>.output Cache_metadata.txt </em></strong>[this directs any further output to the file Cache_metadata.txt]<br /></li><li>at <em>sqlite</em> prompt type <strong><em>Select time_stamp, request_key from cfurl_cache_response; </em></strong>[don't forget the semi colon]<br /></li><li>allow a moment or three for the query to complete the output of it's results<br /></li><li>Launch Microsoft Excel and start the Text Import Wizard selecting (step by step) delimited data, set the delimiters to <strong>Other | </strong>[pipe symbol] and set the Column data format to Text<br /></li><li>Click on Finish then OK and bobs your uncle!<br /></li></ul></p></blockquote><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQW-fLidBrU-9RIawEMqxZfstkgNd0NyyWtEOkFiqlZvTJ5RlyLyBk_U4sWa4hLrDvW5BrlIVjie2Hsxj_n1RFptoImyzafSuWsUyN_8pxC3Gg16WtMRxKhhwtHRLoJFVrqwcxVUdmO_Rq/s800/sqlite_cmd_prompt.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjX8JYkM4vgVlDHBzO6xp8e5oDPAeWnbKl85old1LaE2sKjwKjPi5qyA_9-jk3JDP8Q9merjm-qZ8jn_ENL6rWVQxUT6-jORoxG1TzYX58Jx7IfuGzN1bApoJkf_vf8J61c1gJMGEOsKbl8/s800/sqlite_cmd_prompt-thumb.png" height="121" align="left" width="380" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>Click image to view full size</em><br /><br /></p><blockquote style="clear: both"><p>Method B using <a href="http://sqlitebrowser.sourceforge.net/index.html" target="_blank">SQLite Database Browser</a> as a viewer in Encase<br /><ul style="clear: both"><li>from your Encase case send the Cache.db to SQLite Database Browser<br /></li><li>on the Execute SQL tab type in the SQL string field enter <strong><em>Select time_stamp, request_key from cfurl_cache_response</em><br /></strong></li><li>Review results in the Data returned pane<br /></li></ul>Or<br /><ul style="clear: both"><li>from your Encase case send the Cache.db to SQLite Database Browser<br /></li><li>File/Export/Table as CSV file<br /></li><li>Select the <strong><em>cfurl_cache_response</em></strong> Table name</li><li>Open exported CSV in Excel and adjust time_stamp column formatting (a custom date format is required to display seconds)</li></ul></p></blockquote><p style="clear: both"><strong>Safari cache.db examination methods - contents and metadata</strong><br />What we need to do here is extract the related data from both tables - in other words be able to view the time stamp, URL and the cached object at the same time. This can be done using <a href="http://osenxpsuite.net/?xp=3" target="_blank">SQLite2009 Pro Enterprise Manager</a>. This program has a built in BLOB viewer that will allow you to view the BLOB data in hex and via a image (as in picture) viewer if appropriate.</p><blockquote style="clear: both"><p><ul style="clear: both"><li>Once you have launched the program open your extracted Cache.db file<br /></li><li>In the Query box type (or copy and paste) all in one go<br /><strong><em>SELECT cfurl_cache_blob_data.entry_ID,cfurl_cache_blob_data.receiver_data, cfurl_cache_response.request_key,cfurl_cache_response.time_stamp <br />FROM cfurl_cache_blob_data, cfurl_cache_response <br />WHERE cfurl_cache_blob_data.entry_ID=cfurl_cache_response.entry_ID</em><br /></strong></li><li>Then key<strong> F5 </strong>to execute the query</li><li>This will populate the results tab with the results<br /></li><li>To view the cached object BLOB data in the <em>receiver_data </em>field highlight the record of interest with your mouse (but don't click on <em>BLOB</em> in the<em> receiver_data</em> field). This will populate the hex viewer (bottom left) and the BLOB viewer (bottom right).<br /></li><li>To view a full sized version of a cached image click with your mouse on <em>BLOB</em> in the<em> receiver_data</em> field which launches a separate viewing window<br /></li></ul></p></blockquote><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4qQ3k7Qz3uhCFEaR20Nj6u3qYBZYH5Euthyphenhyphen5Q1ivXb6_WjPIDg67j_R01nQSsGaEzx23dyPuJ4pXgLblPDPxX7z1hePag10dY7CtxHBO23SHD4Qral-NNz2yT5CpBNtJ5XzZ-B8udFZLJ/s800/SQLITEPro2009screenshot1.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgHOLPDIW-uQbhMVPGQEf0h3DEnGJ1SAj-0KxiXi7NRDeuRgIqZDQbH-HpXBvzabaeRP4r9pxnZ7xrtTWHZum1toUXe1tXqNT8ctguBsc3V-mNGmsi_Y7SltNew5IUjHu0rGVqEdVCrvHLO/s800/SQLITEPro2009screenshot1-thumb.png" height="279" align="left" width="378" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>Click on image to view full size</em><br /><br /></p><p style="clear: both"><strong>References</strong><br /><a href="http://www.sqlite.org/fileformat.html" target="_blank">SQLite Database File Format</a><br />Sindro.me weblog - <a href="http://sindro.me/2008/1/20/extracting-data-from-apple-safari-s-cache" target="_blank">Extracting data from Apple Safari's cache</a><br /><a href="http://www.devx.com/dbzone/Article/17403/1954" target="_blank">http://www.devx.com/dbzone/Article/17403/1954</a><br /><a href="http://insidethecore.com/Show%20Notes/show_notes.html" target="_blank">Inside the Core Episode 3 Show Notes</a><br /><a href="http://articles.techrepublic.com.com/5100-10878_11-5141049.html" target="_blank">Define relationships between database tables -Techrepublic</a></p><p style="clear: both"></p><p style="clear: both"></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com2tag:blogger.com,1999:blog-5057815281194312844.post-23534332347540201372010-06-06T14:29:00.000+01:002010-06-08T09:04:35.544+01:00Recovering Safari browser history from unallocated<p style="clear: both">One of my cases involves the examination of an Apple Mac running Mac OSX 10.5.6 Leopard . The primary web browser in use is Safari version 3.2.1. Typically with Safari I run the Comprehensive Internet History search in Encase but in this case the search would not complete so I had to consider another method to recover and review internet history. Browsing history is stored in a binary plist ~ /Users/User_Name/Library/Safari/History.plist however the live one was empty. I recalled from a much earlier case that you can carve deleted plists from unallocated. I had documented a method for doing this over at www.forensicwiki.com but at the time of writing this resource is still offline.</p><p style="clear: both">One of the best file carvers around is <a href="http://www.bladeforensics.com/" target="_blank">Blade</a> and I decided to use it to recover the deleted History.plists. Blade has a number of pre-configured built in Recovery Profiles but there wasn't one for Safari. However one of the neat things about Blade is that you can <a href="http://wordpress.bladeforensics.com/?p=110" target="_blank">write your own profiles</a> and <a href="http://wordpress.bladeforensics.com/?p=90" target="_blank">share them with others</a>. In conversation I had found out that Craig Wilson had written a Safari history.plist recovery profile which he kindly made available to me (after all why re-invent the wheel). I imported it into my copy of Blade and I was then good to go.</p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgGrVGNFquE-5NOLx2Vdk2Sh_Qb5uJKi1yKDVmU_3uj4takRF2tMGJ2j5s5P7zWnLF6lXQCLWMQi6q1vQGQB71DXbvLkYHc4g7LcxJ_02nL6ETtiXw2B3nBMmIS0qAri3GCTFU9KWF2pipL/s800/Recovery_profile_screenshot.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitw5PORuQQ-ha8WSqyHneLBWISQamMHAdl083P-XT3T-liIZjV-bGuADw9eCuwbBtSiDVce4hMbbl-Gxeof2GEXu_LI2QffIqcUDURXFTCgMand67boIsdKDEBOKamoyEVpbK19GxylO6n/s800/Recovery_profile_screenshot-thumb.png" height="258" align="left" width="380" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><em>Click image for a full size version</em><br /><br /><br /><br /></p><p style="clear: both">Another really neat feature with Blade is that you can run it across the Encase evidence files without having to mount them. Having done this in my case Blade recovered over three thousand deleted History.plist files. I then loaded the recovered plist files into <a href="http://www.digital-detective.co.uk/netanalysis.asp" target="_blank">Netanalysis 1.51</a> resulting in over 300,000 internet history records to review. Cool.</p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com0tag:blogger.com,1999:blog-5057815281194312844.post-47997100864258619842010-05-27T11:14:00.000+01:002010-05-27T11:14:27.164+01:00Prefetch and User Assist<p style="clear: both">It seems to me that more and more cases I see only have evidence within unallocated clusters. It is also a frustration that the CPS seem less and less interested in any artefact found there. They seem to have the view that any thing currently living in unallocated clusters somehow magically arrived there and has nothing whatever to do with the computer's user.</p><p style="clear: both">Obviously we try and address this misconception, by trying to investigate how the evidence in question came to be on the computer, and to a lesser extent how it came to be deleted. Which brings me on to another frustration - file wiping software. This is another thing I see more and more. Properly configured file wiping software eliminates the little fragments of evidence we use to piece our cases together. </p><p style="clear: both">Recently I was faced with this scenario - evidence could only be found in unallocated and there was file wiping software sat there in program files. Sentencing Advisory Panel guidelines allude to the presence of file wiping software being an aggravating factor to consider when sentencing. But in this case it occurred to me that it would be evidentially useful to know just how often my suspect used the file wiping software concerned. File time stamps may indicate when the program was last executed and installation dates can be discerned from a variety of locations (registry entries, folder creation dates and so on) but where do you establish how often the program was used? You never know -it may write to a log file or create event log entries but many don't. In my case the answer lay in two areas - Prefetch and User Assist.</p><p style="clear: both"><strong>Prefetch</strong><br />My suspect was using Microsoft Windows XP. This OS (as the later Vista and Windows 7) performs application and boot prefetching. This process is designed to speed up the loading of applications (with regards to application prefetching) by storing data required by the program during the first ten seconds of use in a file - a prefetch file. These files are stored in the Windows/Prefetch folder and have a .pf file extension. The file names are a combination of the applications name and a hash of its file path. The hash may be useful in some cases because it could indicate that an application lives in more than one location (which is often suspicious). Some work on analysing the hash algorithm has been carried out by <a href="https://42llc.net/index.php?option=com_myblog&show=Prefetch-Hash-Algorithm.html&Itemid=39" target="_blank">Yogesh Khatri at 42llc</a>. The files themselves contain some useful information including last time of execution, the number of times the program was run and references to files and the file system utilised by the program in its first ten seconds of use. Unfortunately prefetch files are not differentiated by user. In my case the file wiping software had a prefetch file. There are a number of options open to us to analyse the prefetch file.</p><p style="clear: both">If all you need is the time of last execution and number of time the application was run for just one file you may as well do it manually. For Windows XP at file offset 120 an 8 byte Windows Filetime is stored which is the Last Execution Time. At file offset 144 the number of executions is stored as a four byte Dword. For Vista and Windows 7 the offsets are different - 128 and 152 respectively.<br /><br /></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUoQdIdtzLFIT7RQcFiMQNn9iitIjFJuyF6tfnmHTPoE3dUYrdP-LVEwl4DQdwMPT8vruX-eAAvQx3KR4Ukl27hYS5QrKqce_inw3eLd0fESNqnz6lF5IQW3Yyh_5j1mCQaDweixSNB4UH/s800/execution_date.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjUiKbf92-YJavz5T1UZ4T_qZ5qylqDMqLDtY-MD-dSTP4msvBsv1J1fFUDCS3ApMJ7PiKSCzJ6xTofddgQ1m7jXvZM-iBn-C7ktpnQl4FGrnD4ZLpC79siYz-2K6ZrbvyWxKWGCGcmoWbJ/s800/execution_date-thumb.png" height="201" align="left" width="380" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br /><em>Bookmarking Last Execution Time and Date</em><br /><br /><br /><br /><br /></p><p style="clear: both"><br /><br /></p><p style="clear: both"></p><p style="clear: both"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiUQexGuDJeJMsAPXaeCusBTof9rLgT_ImOkW6fMu5SnSQu-BxbH6c2992Cvkg-5qqcqPI_JrWuKhaoc-_OaLMftxAheons7T3agV6XW_62_k5QpGm4NHKoulskp4tK_I4tbmf4a9JPYcNi/s800/number_of_executions.png" class="image-link"><img class="linked-to-original" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhywCBXFzdOPqXLRxTbUZkoAEqdyIf7veNAqbc7vpLXocA0ReeMmcELDeQNPbFIW-tubh4JOq1ehJsgKNqGFO4kxws0TeHoZkuzjs0z1nX-6zk1xXa0m2Ot7DHa8I38wFaWl3H-Lgx3atMg/s800/number_of_executions-thumb.png" height="302" align="left" width="324" style=" display: inline; float: left; margin: 0 10px 10px 0;" /></a><br /><em> Bookmarking number of times the application was run</em></p><p style="clear: both"></p><p style="clear: both">If you have a number of prefetch files to analyse or you wish to corroborate your findings you could try the <a href="https://42llc.net/index.php?option=com_myblog&show=Prefetch-Hash-Algorithm.html&Itemid=39" target="_blank">Mitec Windows File Analyzer</a> program or run an enscript. Guidance Software's download center has two enscripts that fit the bill. <a href="https://support.guidancesoftware.com/forum/downloads.php?do=file&id=427" target="_blank">PfDump.Enpack</a> and <a href="https://support.guidancesoftware.com/forum/downloads.php?do=file&id=649" target="_blank">Prefetch File Analysis</a>. Pfdump outputs to the console and the Prefetch File Analysis enscript outputs to bookmarks.</p><p style="clear: both"><strong>UserAssist</strong><br />UserAssist is a method used to populate a user's start menu with frequently used applications. This is achieved by maintaining a count of application use in each users NTUSER.DAT registry file. I use Access Data's Registry Viewer application to parse and decode this information. Simon Key has written a cool enscript which is bang up to date with Windows 7 support. Detailed information, including the changes introduced with Windows 7, and the script can be found within GSI's <a href="https://support.guidancesoftware.com/forum/downloads.php?do=file&id=832" target="_blank">download center</a>.</p><p style="clear: both">In my case I encountered a possible anomaly in that the Prefetch and UserAssist run counts were different. With multiple users you would expect this as the Prefetch run count is not user specific. I had only one user in my case and the UserAssist count was significantly greater albeit that both were four figure numbers. A possible explanation is that if the application's prefetch file is deleted when the application is next used the prefetch run count starts again from 1.</p><p style="clear: both"><strong>References</strong><br /><a href="https://42llc.net/index.php?option=com_myblog&show=Prefetch-Files-Revisited.html&Itemid=39" target="_blank">https://42llc.net/index.php?option=com_myblog&show=Prefetch-Files-Revisited.html&Itemid=39 </a><br /><a href="http://en.wikipedia.org/wiki/Prefetcher" target="_blank">http://en.wikipedia.org/wiki/Prefetcher </a><br /><a href="http://members.rushmore.com/~jsky/id14.html" target="_blank">http://members.rushmore.com/~jsky/id14.html </a><br /><a href="http://members.rushmore.com/~jsky/id37.html" target="_blank">http://members.rushmore.com/~jsky/id37.html </a><br /><a href="http://jessekornblum.com/presentations/dodcc08-2.pdf" target="_blank">http://jessekornblum.com/presentations/dodcc08-2.pdf</a><br /><br /></p><br class='final-break' style='clear: both' />DC1743http://www.blogger.com/profile/14186532367794900206noreply@blogger.com4