http://www.secuobs.com Observatoire de la securite Internet fr webmaster@secuobs.com 2014-11-10 12:33:18 - Forensics from the sausage factory : Recognising FileVault2 encryption 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 IMAGE Figure 1 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 NameFileVault 2 partitions all have a Partition Type GUID as shown in Figure 2 IMAGE Figure 2 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 IMAGE Figure 3 The second 128 byte partition entry is highlighted in light blue The Partition Name Macintosh HD is visible from offset 56 within the partition entry 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 IMAGE Figure 4 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 IMAGE Figure 5 Imaging FileVault2 volumes 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 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 Evidence File Converter enscript 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 Next plug your external disk containing your DMG files into your Mac mine is running the Yosemite OS and launch Terminal Enter the command hdiutil attach -nomount path_to_your_dmg_files tip -drag the first dmg file into the terminal window to auto populate the path IMAGE Figure 6 We can see the FileVault2 volume detailed in Figure 6 at dev disk2s2 described as a Apple_CoreStorage partition Your Mac should ask you for the passphrase to unlock the disk as shown in Figure 7 IMAGE Figure 7 Once you have entered the passphrase, in the terminal enter the command diskutil list We can see in Figure 8 that the disk image is listed as dev disk2 and the unlocked encrypted volume is listed as dev disk3 disk0 is my Macs hard disk and disk1 is the external disk containing the converted DMG files IMAGE Figure 8 All that's left to do now is image the unlocked encrypted volume dev disk3 In the terminal enter the command sudo dd bs 1m if dev disk3 of path to your output disk output filenamedd Once the dd image is completed you can add it into your case via the add raw image option Hope this helps someone http://www.secuobs.com/revue/news/544592.shtmlhttp://www.secuobs.com/revue/news/544592.shtml Secuobs.com : 2014-04-09 19:01:38 - Forensics from the sausage factory - Just as I've found the time to write up a blog post along comes an appropriate time related subject 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 Macs Mountain Lion and Mavericks for certain and probably most earlier versions will Set date and time automatically whilst connected to the internet as shown in Figure 1 IMAGE Figure 1 The problem to overcome then was to establish where this setting was stored - I knew it would be in a plist somewhere - isn't everything Mac related stored in a plist - So many plists 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 overridesplist in the Finder at the path private var db launchddb comapplelaunchd IMAGE Figure 2 This plist is an xml plist so it can be read easily Figure 3 shows this plist within the Property List Editor IMAGE Figure 3 The key we are interested in is the orgntpntpd key If the Disabled value is true Set date and time automatically is turned off Hope this helps someone Richard http://www.secuobs.com/revue/news/507326.shtmlhttp://www.secuobs.com/revue/news/507326.shtml Secuobs.com : 2013-12-10 13:01:19 - Forensics from the sausage factory - Recently I have had cause to look again at how the Apple Safari web browser stores cache Surprisingly much of what I wrote concerning Safari back in 2010 still holds true The introduction of OSX Lion brought some changes in that a new table cfurl_cache_receiver_data was created within the SQLite cachedb database and used to store the cached item as a binary large object in the receiver_data field Previously this field was within the cfurl_cache_blob_data table 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 cachedb In Figure 1 we can see a number of entries in the cfurl_cache_receiver_data table A number of them contain BLOBs as expected but in entry 18109 we can see that the new field isDataOnFS has a value of 1 and the receiver_data field has a value of ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E IMAGE Figure 1 In Figure 2 we can see that the new fsCachedData folder contains the file ED6AC03A-4E37-46E2-8C95-E29EDC92BF6E IMAGE Figure 2 It appears that any file 4,096 bytes and larger is now cached externally in the fsCachedData 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 The eagle eyed amongst my readers will have already spotted another type of entry within the receiver_data field in Figure 1 Figure 3 shows more of them IMAGE Figure 3 It can be seen that the data in the receiver_data field has the structure '4749463B' 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 Until next time Richard http://www.secuobs.com/revue/news/485353.shtmlhttp://www.secuobs.com/revue/news/485353.shtml Secuobs.com : 2013-03-04 20:27:06 - Forensics from the sausage factory - 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 In Figure 1 we can see the first part of a jpg taken with an iPhone5 IMAGE Figure 1 My readers will recognize the start of the jpg header 0xFF 0xD8 0xFF etc etc but I want to draw your attention to 0x4D 0x4D These two bytes are the start of a section of data known as a TIFF structure and are part of an 8 byte header The TIFF file specification published by Adobe details the information residing in this header IMAGE Figure 2 In ASCII these bytes are read as MM 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 0x00 0x2A 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 note the HHGTTG reference 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 IFD is an Image File Directory Adobe defines it as a 2 byte count of the number of directory entries ie 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 We can see that in this case we have 0x00 0x0a 10 12 byte directory entries the start of each being marked in green Adobe details the structure of each entry as follows Bytes 0-1 The tag that identifies the field Bytes 2-3 The field type Bytes 4-7 the number of values, Count of the indicated type Bytes 8-11 The Value Offset, the file offset in bytes of the Value of the field The tag we are interested in within the IFD is 0x88 0x25 A comprehensive list of tag numbers can be found at wwwexiv2org tagshtml 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 0x00 0x04 This indicates that the field type is type 4 Adobe details the possible field types as follows 1 BYTE 8-bit unsigned integer 2 ASCII 8-bit byte that contains a 7-bit ASCII code the last byte must be NUL binary zero 3 SHORT 16-bit 2-byte unsigned integer 4 LONG 32-bit 4-byte unsigned integer 5 RATIONAL Two LONGs the first represents the numerator of a fraction the second, the denominator 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 0x00 0x00 0x00 0x01 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 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 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, ie, stored in the lower numbered bytes Whether the Value fits within 4 bytes is determined by the Type and Count of the field 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 0x00 0x00 0x02 0x5A are the value itself You will recall that the 0x88 0x25 tag is used to store a pointer to the GPS Info IFD 0x00 0x00 0x02 0x5A 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 0x00 0x09 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 green IMAGE Figure 3 The GPS IFD has a series of potential tag values A comprehensive list can be found at http wwwawaresystemsbe imaging tiff tifftags privateifd gpshtml From this list we can see that the tags of most interest here are Hex Name Description 0001 GPSLatitudeRef ------ Indicates whether the latitude is north or south latitude 0002 GPSLatitude ---------- Indicates the latitude 0003 GPSLongitudeRef ---- Indicates whether the longitude is east or west longitude 0004 GPSLongitude --------- Indicates the longitude IMAGE Figure 4 Figure 4 above shows the GPSLatitudeRef entry 0x00 0x01 is the tag number 0x00 0x02 indicates the value is stored as ASCII 0x00 0x00 0x00 0x02 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 0x53 decodes in ASCII to uppercase S followed by 0x00 The GPS LongitudeRef entry decodes in a similar fashion IMAGE Figure 5 Figure 5 above shows the GPSLatitude entry 0x00 0x02 is the tag number 0x00 0x05 indicates that the type of value stored is a RATIONAL 0x00 0x00 0x00 0x03 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 0x00 0x00 0x02 0xCC indicate where the value is stored offset from the start of the TIFF structure In this case the offset is 716 IMAGE Figure 6 Figure 6 above shows the three RATIONALs at offset 716 Each RATIONAL consists of two LONGs highlighted in red and yellow The first LONG represents the numerator of a fraction, the second LONG the denominator We can decode the RATIONAL values as follows 0x00 0x00 0x00 0x06 0x00 0x00 0x00 0x01 6 1 60x00 0x00 0x05 0xFC 0x00 0x00 0x00 0x64 1532 100 15320x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0 1 0 The specification for storing the latitude states the 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 It can be seen here that the latitude is stored in degrees and minutes IMAGE Figure 7 Figure 7 above shows the GPSLongitude entry 0x00 0x04 is the tag number 0x00 0x05 indicates that the type of value stored is a RATIONAL 0x00 0x00 0x00 0x03 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 0x00 0x00 0x02 0xE4 indicate where the value is stored offset from the start of the TIFF structure In this case the offset is 740 IMAGE Figure 8 Figure 8 above shows the three RATIONALs at offset 740 Each RATIONAL consists of two LONGs highlighted in blue and yellow 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 0x00 0x00 0x00 0x6A 0x00 0x00 0x00 0x01 106 1 6 0x00 0x00 0x12 0xFE 0x00 0x00 0x00 0x64 4862 100 4862 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0 1 0 The specification for storing the longitude states 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 It can be seen here that the longitude is stored in degrees and minutesTo confirm our findings I have used Irfan View to examine the EXIF data, the GPS data can be seen in Figure 9 below IMAGE Figure 9 For the curious the actual photograph is below IMAGE Figure 10 The location can be viewed on a map at http mapsgooglecom maps q -6255333,106810333 z 15 Referenceshttp partnersadobecom public developer en tiff TIFF6pdfhttp wwwexiv2org tagshtmlhttp wwwawaresystemsbe imaging tiff tifftags privateifd gpshtml http://www.secuobs.com/revue/news/431320.shtmlhttp://www.secuobs.com/revue/news/431320.shtml Secuobs.com : 2012-05-15 13:41:15 - Forensics from the sausage factory - A recent case was unusual because most of the ipoc were located by the police examiner in a folder entitled MessengerCache at the path C Users AppData Local Temp MessengerCache 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 Remote User Tile and Remote User Theme Picture respectively have been received from the remote user Mars with whom the local user is engaged in an instant messaging conversation image 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 MessengerCache folder In the case that the picture concerned was ipoc 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 MessengerCache folder In figure 2 the screenshot shows the local user s conversation window after the remote user Mars 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 MessengerCache folder image Figure 3 below illustrates a forensic examination of the local user s MessengerCache folder It can be seen that it contains the Remote User Tile and Remote User Theme Picture 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 image 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 MessengerCache folder The defendant pleaded guilty to one count of possession not related to the MessengerCache pictures http://www.secuobs.com/revue/news/375582.shtmlhttp://www.secuobs.com/revue/news/375582.shtml Secuobs.com : 2012-05-15 12:54:31 - Forensics from the sausage factory - 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 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 15 megabytes per second MB s which equates to 54 Gigabytes per hour There were not going to be enough hours in this weekend to image both arrays on the server What I did next I thought might be worth sharing with you I used dd to create a source image, netcat to pipe it to an onsite laptop across a network and ewfacquirestream to capture the dd 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 146 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 Method to image computers across a network 1 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 DEFT 7 forensic linux distro 2 To configure Ethernet settings on both using Gigabit NICs 10 100 1000 if available Launch terminal and at prompt type sudo su At prompt type ifconfig to identify network cards At prompt type ifconfig eth0 1921680100 on onsite laptop and ifconfig eth0 1921680101 on machine to be imaged these commands assume that you are pugged into eth0 if there is more than one NIC on the computer to be imaged it might be eth1 or higher Test connection by typing at prompt ping c 5 1921680100 or ping c 5 1921680101 as appropriate 3 On on-site laptop Connect collection hard disk drive Launch terminal and at prompt type sudo su At prompt type fdisk l to identify storage drive Create a folder to mount the storage drive to by typing mkdir mnt name of your folder Next mount the storage drive to your folder by typing mount dev sdb2 or whatever mnt name of your folder Now we create a netcat listener and a pipe to ewfacquirestream at prompt type but donʼt press enter just yet 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 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 4 On machine to be imaged At prompt type sudo su At prompt type fdisk l to identify drive to be imaged Next we prepare to dd drive to be imaged and pipe to netcat at prompt type dd if dev sdb conv noerror,sync bs 4096 nc 1921680100 1234 but donʼt press enter if you are imaging a server with an HP Raid card the command might look something like dd if dev cciss c0d0 bs 4096 conv noerror,sync nc 1921680100 1234 5 Start imaging process by Press enter within terminal on onsite laptop first to start netcat listener Then press enter within terminal on machine to be imaged to start dd 6 When the acquisition completes ewfacquirestream outputs a MD5 hash calculated over data value to the terminal Either photograph this value or copy and paste it to a text file on your collection hard disk drive Notes re imaging speed 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 396 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 ie change from none to fast Sometimes either doubling or halving the block size on both source and receiver machines can make a difference also http://www.secuobs.com/revue/news/375571.shtmlhttp://www.secuobs.com/revue/news/375571.shtml Secuobs.com : 2012-02-08 15:15:03 - Forensics from the sausage factory - Like buses you wait all day for one and then two come along at once A recent case involved a number of images found within a file entitled FileSystem_NodesMYD on an Apple Snow Leopard box 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 FileSystem_NodesMYD was Library Caches Adobe Bridge CS3 Cache data BridgeStore FileSystem_NodesMYD and within the same folder were two other files of note FileSystem_NodesMYI and FileSystem_Nodesfrm 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 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 image Figure 1 I was tasked with ascertaining more information about each picture located within the FileSystem_NodesMYD file So in order to do this I installed MySQL version 5520 on a test Apple iMac running Snow Leopard I would expect that a MS Windows version would work just as well 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 Then I copied the BridgeStore folder into the default location for MySQL databases which was at the path Macintosh HD usr local mysql-5520-osx106-x86 data on my Mac and restarted the MySQL database server Using MySQL Administrator I could view some information relating to the BridgeStore database image Figure 2 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 RazorSQL On the menu bar of this program there is a Connections option Select this and Add Connection Profile Work through the wizard, the bulk of the configuration can be seen in Figure 3 Screen shot 2012-02-08 at 131625 Figure 3 When you are connected you can enter queries in the top right hand pane The query show columns from FileSystem_Nodes tells us that each record within the table has 52 fields as shown in Figure 4 Screen shot 2012-02-08 at 134020 Figure 4 The fields of particular interest are displayPath , created , thumbnail and preview Other useful SQL queries may include Select from FileSystem_Nodes or Select id, displayPath, created from FileSystem_Nodes 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 Binary Data Editor, in the resulting window click on the View Image button In summary it was possible to establish the original path and date created for each picture carved from the FileSystem_Nodesmyd file using this method References http http enwikipediaorg wiki MyISAM http devmysqlcom doc refman 55 en myisam-storage-enginehtml http://www.secuobs.com/revue/news/356678.shtmlhttp://www.secuobs.com/revue/news/356678.shtml Secuobs.com : 2012-02-08 13:00:30 - Forensics from the sausage factory - No not me although I have been missing for some time I m talking about the registry key HKEY_CURRENT_USER Software Microsoft Windows CurrentVersion Internet Settings Url History DaysToKeep For those of us looking at dead boxes this key can be found within each users NTUSERdat 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 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 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 HistorySettings Figure 1 It has been suggested to me that in the absence of the registry key detailed above the registry key HKEY_LOCAL_MACHINE Software Microsoft Windows CurrentVersion Internet Settings Url History DaysToKeep 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 Until next time http://www.secuobs.com/revue/news/356642.shtmlhttp://www.secuobs.com/revue/news/356642.shtml Secuobs.com : 2011-07-03 00:24:22 - Forensics from the sausage factory - This is the fourth post dealing with the elements making up SQLite databases and complements the previous three Carving SQLite databases from unallocated clusters SQLite Pointer Maps pages An analysis of the record structure within SQLite databases We will remember from these previous posts that The entire database file is divided into equally sized pages - SQLite database files always consist of an exact number of pages The page size is always a power of two between 512 29 and 65536 216 bytes All multibyte integer values are read big endian The page 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 Pages are numbered beginning from 1, not 0 Therefore to navigate to a particular page when you have a page number you have to calculate the offset from the start of the database using the formula offset page number-1 x page size and that the database may have the following possible page types An index B-Tree internal node An index B-Tree leaf node A table B-Tree internal node A table B-Tree leaf node An overflow page A freelist page A pointer map page The locking page In this post I am going to take a closer look at Overflow pages 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 Cachedb file maintained by the Apple Safari web browser One of the tables within this database is entitled cfurl_cache_blob_data which uses the receiver_data field to store the cached item itself eg cached jpgs, gifs, pngs, html et al as a BLOB A BLOB is a Binary Large OBject These cached objects often require overflow pages and we can demonstrate the mechanics of them by walking through a record within Cachedb If you run a file carver across a Cachedb file searching for pictures you are likely to carve out a number corrupt pictures as shown in the example within Figure 1 IMAGE Double click to enlargeFigure 1 It can be seen that this picture starts at File offset 4583317 within Cachedb 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 IMAGE Double click to enlargeFigure 2 As discussed in my earlier post An analysis of the record structure within SQLite databases 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 cfurl_cache_blob_data table is almost bound to overflow the 1024 byte database pageIn 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 44758955078125 and round up to establish the page number Our corrupt picture header is in page 4476The SQLiteorg file format states that 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 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 offset page number-1 x page size 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 IMAGE Double click to enlargeFigure 3 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 listI 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 hey presto IMAGE 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 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 cachedb 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 follows the Pointer Map page Pointer Map pages found in Safari Cachedb 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 0x01 0x00 0x00 0x00 0x00 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 0x02 0x00 0x00 0x00 0x00 This record relates to a free page, which also does not have a parent page 0x03 0xVV 0xVV 0xVV 0xVV where VV indicates a variable 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 0x04 0xVV 0xVV 0xVV 0xVV where VV indicates a variable 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 0x05 0xVV 0xVV 0xVV 0xVV where VV indicates a variable 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 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 2048 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 21834146341463415, 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 offset page number-1 x page size 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 IMAGE Double click to enlargeFigure 4 It can be seen that the 169th record is in hex 04 00 00 11 7B 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 04 00 00 11 7A This record also 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 03 00 00 11 6E 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 4462Using the formula offset page number-1 x page size 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 An analysis of the record structure within SQLite databases shown in Figure 5 IMAGE Double click to enlarge Figure 5 Figure 5 shows the page header of the B-tree leaf node page The first byte 0D is a flag indicating the page is a table B-tree leaf node The next two bytes 00 00 indicate that there are no free blocks within the page The next two bytes 00 03 read big endian indicate that there are three cells stored on the page The next two bytes at offset 5 within the page header 00 EB 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 00 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 02 60, 01 F1 and 00 EB 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 Length of Payload and Row ID see Figure 6 IMAGE Double click to enlargeFigure 6 The varints are B1 66 and 82 11 The calculation needed to decode them follows in Figure 7 IMAGE Double click to enlarge Figure 7 Following the Length of Payload and Row ID are varints representing the Length of the Payload Header and the serial type codes of the entry_ID, response_object, request_object, receiver_data, proto_props and user_info fields respectively as shown in Figure 8 IMAGE Double click to enlargeFigure 8 Figure 8 shows highlighted in blue and green the first three elements of the Cell make up - the Payload Length, the Row ID and the Payload Header We have already decoded the Payload Length B1 66 and the Row ID 82 11 The next byte h0A denotes the length of the Payload Header which is in this case 10 bytes including the Payload Header Length byte It can be seen therefore that the remaining 9 bytes contain the varints 00, 9B 54, 96 3E, B1 4A, 00 and 00 To determine what each varint indicates we have to consult the Serial Type Code chart detailed in the post An analysis of the record structure within SQLite databases Each Serial Type Code details the type and length of the data in the payload that follows the payload header 00 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 SQLiteorg file format states 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 9B 54 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 96 3E 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 B1 4A 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 00 This serial type code indicates that the field is NULL 00 This serial type code indicates that the field is NULL The serial type code for the response_object 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 IMAGE Double click to enlarge Figure 9 The first blue shaded are is the cell broken down above The last four bytes of this cell highlighted in darker blue is the hex value 00 00 11 7A 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 Next PostFollowing 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 References http wwwsqliteorg fileformathtml http wwwsqliteorg fileformat2html http://www.secuobs.com/revue/news/314908.shtmlhttp://www.secuobs.com/revue/news/314908.shtml Secuobs.com : 2011-05-10 19:41:09 - Forensics from the sausage factory - My two previous posts Carving SQLite databases from unallocated clusters and SQLite Pointer Maps pages 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 Background 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 Firefox 3 History Recovery FF3HR is an application written to recover Firefox records A paper entitled Forensic analysis of the Firefox 3 Internet history and recovery of deleted SQLite records written by Murilo Tito Pereira also deals with the recovery of Firefox recordsSQLite 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 Table Record IMAGE Figure 1 Figure 1 shows, as viewed with the SQLite Database Browser 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 id, a url, a title, a visit_count, a typed_count, a last_visit_time, a hidden flag and lastly a favicon _id To aid viewing I will repeat the record data below ID 608 URL http wwwsqliteorg fileformat2html title File Format For SQLite Databases visit_count 1 typed_count 0 last_visit_time 12949409092779476 hidden 0 favicon_id 46 The urls 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 CellsLets recap some of the information dealt with in the earlier post Carving SQLite databases from unallocated clusters 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 IMAGE Figure 2 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 cell content area 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 The number of cells and their location within a database page is stored within the B-Tree page header at the following offsets Offset 1 2 bytes 16 bit integer read big endian Byte offset of first block of free space on this page 0 if no free blocks Offset 3 2 bytes 16 bit integer read big endian Number of entries cells on the page Offset 5 2 bytes 16 bit integer read big endian 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 IMAGE Figure 3 Page Header and Cell Pointer array 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 0D is a flag indicating the page is a table B-tree leaf node The next two bytes 00 00 indicate that there are no free blocks within the page The next two bytes 00 03 read big endian indicate that there are three cells stored on the page The next two bytes at offset 5 within the page header 0B 8E 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 00 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 0C 44, 0B EC and 0B 8E are the cell pointer array for this page The SQLiteorg file format notes helpfully state that 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 The key 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 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 IMAGE Figure 4 Cell make up Figure 4 indicates four areas of interest The payload 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 payload header details how we can identify each field within the concatenated data see the Payload Header section below for details of how this works The Row ID number and the Payload length are stored using variable length integers known as varints To successfully decode the Cell and Payload headers we have to be able to decode a varint Varint http wwwsqliteorg fileformat2html and http wwwsqliteorg fileformathtml varint_format provides some detail in respect to how varints 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 Varints are variable length integers between 1 and 9 bytes in length depending on the value stored They are a static Huffman encoding of 64-bit twos-complement integers that uses less space for small positive values 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 Varints are big-endian bits taken from the earlier byte of the varint are the more significant than bits taken from the later bytes Seven bits are used from each of the first eight bytes present, and, if present, all eight from the final ninth byte IMAGE Figure 5 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 varint The first byte is 5B We have to establish the value of the most significant bit and this can be done by converting the hex 5B to binary IMAGE It can be seen that in this case the most significant bit is zero and therefore not set This varint 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 The next byte is 84 Converting this to binary IMAGE The most significant bit here has the value of one and therefore is set This indicates that this varint includes, at least, the next byte 60 which converted to binary IMAGE 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 varint To establish the value of this varint we now have to take the least significant 7 bits of each of the two contributing bytes and concatenate them together 00001001100000 We discard the leading zeros and convert the binary 1001100000 to decimal, giving a value of 608 This varint represents the row ID and we can see in figure 1 that the row ID is confirmed as 608 The calculation we have carried out can be represented by a formula If we say that the value of the varint is N and the unsigned integer value of the first byte is x and the unsigned integer value of the second byte is y we can use the formula N x-128 x 128 y If we substitute the value of our unsigned integers 132 and 96 into the formula 132-128 x 128 96 608 This formula works for two byte varints that can represent a maximum value of 16383 I suspect we are not likely to encounter larger varints 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 varint is less than 128 you can exclude the possibility of there being a second byte in the varint Payload Header and PayloadWe have already looked at two of the four areas of interest within a cell, the payload length and row ID Next up is the Payload Header and Payload IMAGE Figure 6 Payload Header make up Figure 6 shows the make up of the payload header of a record within the URLs table of the Google Chrome History SQLite database The payload is the data forming the record stored in a serialized way with all the relevant data concatenated together The payload header 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 Payload Header Length followed by one or more Serial Type Codes The Serial Type Code 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 varints and are detailed in a chart provided by SQLiteorg at Figure 7 IMAGE Figure 7 Lets have a look at the Payload Header of our example record detailed in Figure 1 IMAGE Figure 8 Figure 8 shows highlighted in blue and green the first three elements of the Cell make up shown in Figure 4 - the Payload Length, the Row ID and the Payload Header We have already decoded the Payload Length 5B and the Row ID 84 60 The next byte h09 denotes the length of the Payload Header which is in this case 9 bytes including the Payload Header Length byte It can be seen therefore that the remaining 8 bytes shown in hex are 00, 59, 4D, 01, 01, 06, 01 and 01 These bytes represent varints 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 varint is only a single byte in length To determine what each varint 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 payload that follows the payload header The multi byte integers are decoded big endian 00 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 SQLiteorg file format states 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 59 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 4D 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 01 This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte 01 This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte 06 This serial type code has a value of 6 indicating the next field is an 64 bit integer using 8 bytes 01 This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte 01 This serial type code has a value of 1 indicating the next field is an 8 bit integer using 1 byte It can be seen that our payload is 82 bytes in length 38 32 1 1 8 1 1 The payload header was 9 bytes and therefore the overall payload length is 91 82 9 bytes, as previously calculated, and represented by the byte 5B IMAGE Figure 9 Figure 9 shows each element of the payload highlighted alternately in green and blue The first element is http wwwsqliteorg fileformat2html 38 bytes in length, the next element is File Format For SQLite Databases 32 bytes in length The next element is represented by the byte 01 which denotes the visit_count of 1 This is followed by the byte 00 denoting the typed_count of 0 Next are the eight bytes 00 2E 01 6B 41 06 BD D4 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 00, the hidden flag, followed lastly by 2E decoded as 46, the favicon_ID The next record in this case immediately follows at offset 3052 within the database page Notes 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 - Carving Considerations 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 presentation presented by Alex Caithness of CCL details an approach that can be adopted for carving iPhone callsdb databases Deleted Data within Live Databases This area will require another blog post on another day I am aware of two programs possibly written to recover this deleted data SQL Undeleter from Chirashi Security and Epilog from CCL If the developers will let me test these programs out I will report the results to you References http wwwsqliteorg fileformathtml http wwwsqliteorg fileformat2html http wwwccl-forensicscom images f3pourcents20presentation3pdf http mobileforensicswordpresscom 2011 04 30 sqlite-records http://www.secuobs.com/revue/news/303844.shtmlhttp://www.secuobs.com/revue/news/303844.shtml Secuobs.com : 2011-05-04 13:44:22 - Forensics from the sausage factory - This blog post complements and should be read in conjunction with the previous post Carving SQLite databases from unallocated clusters In that post I looked at the information available within an SQLite database that may assist in carving one from unallocated clusters You will remember from the earlier blog post that SQLite databases are divided into equally sized pages and SQLite database files always consist of an exact number of pages The page 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 page in an SQLite database is numbered page 1 Auto-vacuum capable Auto-vacuum capable SQLite databases make use of Pointer Map pages along with the other page types detailed in the earlier blog post It is probably helpful to provide some information about what an auto-vacuum capable database is In a non-auto-vacuum-capable SQLite database when information is deleted the pages where it was stored are added to a list of free pages 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 When Auto-vacuum is enabled all free pages are moved to the end of the database file and the database file is truncated to remove the free pages at every transaction commit, thus removing free pages automatically Pointer Map Pages 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 pages parent page 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 In auto-vacuum-capable SQLite databases page 2 of the database is always a Pointer Map page Pointer Map pages store a 5 byte record relating to every page that follows the Pointer Map page For example if we have an auto-vacuum-capable database that has 24 pages each of 4096 bytes in size in total, page 1 will contain the database header and the database schema and the next page, page 2, will be a Pointer Map page This Pointer Map page will contain a 5 byte record for every one of the remaining 22 pages taking up 110 bytes of space within the page The first 5 byte record begins at the very beginning of the Pointer Map page and therefore in a 4096 byte page a maximum of 819 4096 5 records can be stored If the database has more than 821 pages when using a page size of 4096 bytes page 822 would be an additional Pointer Map page that would contain records for the next 819 pages following this second Pointer Map page Further additional Pointer Map pages can be added in the same way Pointer Map pages do not store records relating to Pointer Map pages or page 1 of the database 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 0x01 0x00 0x00 0x00 0x00 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 0x02 0x00 0x00 0x00 0x00 This record relates to a free page, which also does not have a parent page 0x03 0xVV 0xVV 0xVV 0xVV where VV indicates a variable 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 0x04 0xVV 0xVV 0xVV 0xVV where VV indicates a variable 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 0x05 0xVV 0xVV 0xVV 0xVV where VV indicates a variable 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 IMAGE Figure 1 The screenshot at Figure 1 shows the Pointer Map page of an iPhone SMSdb 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 Extrapolating the database size from the Pointer Map page If you count the Page Type bytes highlighted within Figure 1 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 Figure 1 Carving Considerations To carve auto vacuum capable databases the following steps would be needed Identify first page of database by detecting the SQLite format 3 header Establish page size by reading the 2 bytes at offset 16 as a 16 bit integer big endian Check the 4 byte 32 bit integer at offset 52 for a non zero value indicating that the database is auto vacuum capable Go to page 2 of the database at Offset page size If value is 0x01 or 0x02 or 0x03 or 0x04 or 0x05 set a counter to 1 Move five bytes forward and if value is 0x01 or 0x02 or 0x03 or 0x04 or 0x05 increment the counter by 1 or if the value is not 0x01 or 0x02 or 0x03 or 0x04 or 0x05 begin the calculation of database file size using the formula database size counter value 2 x page size The above discounts the possibility of their being more than one pointer map page Some additional logic would be needed to cater for this eventuality Pointer map pages may contain page size 5 records If the counter increments to a point where it equals this value it would be necessary to locate the next pointer map page using the formula next pointer map page number page size 5 2 number of existing pointer map pages To calculate the offset to this page use the formula offset page number-1 x page size References http wwwsqliteorg fileformathtml http wwwsqliteorg fileformat2html http wwwsqliteorg src artifact cce1c3360c http://www.secuobs.com/revue/news/302535.shtmlhttp://www.secuobs.com/revue/news/302535.shtml Secuobs.com : 2011-04-27 21:08:23 - Forensics from the sausage factory - Have you missed me Background 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 egFirefox, 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 Forensic analysis of the Firefox 3 Internet history and recovery of deleted SQLite records written by Murilo Tito Pereira became available in 2009 at a cost but my interest was piqued more recently when Rasmus Riis who I believe works for Law Enforcement in Denmark posted an enscript he had written - Chrome SQlite db finder v14 to Guidance Software's enscript download center Rasmus Riis's 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 page 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 SMSdb used by the iPhone So as a result I took a closer look at the problem SQLite Database Structure and File Format The SQLite file format is well documented at http wwwsqliteorg fileformathtml and also at http wwwsqliteorg fileformat2html 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 Size and numbering The entire database file is divided into equally sized pages - SQLite database files always consist of an exact number of pages The page size is always a power of two between 512 29 and 65536 216 bytes All multibyte integer values are read big endian The page 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 Pages are numbered beginning from 1, not 0 Therefore to navigate to a particular page when you have a page number you have to calculate the offset from the start of the database using the formula offset page number-1 x page size Possible Page Types Each page is used exclusively to store one of the following An index B-Tree internal node An index B-Tree leaf node A table B-Tree internal node A table B-Tree leaf node An overflow page A freelist page A pointer map page The locking page However not every database will include all of these items The first page page 1 The first page of the database is a special page for two reasons it contains within the first 100 bytes of the page the database header and it also contains the Database Schema the structure of the database tables, indexes etc described in formal language The database header begins with the following 16 byte sequence 0x53 0x51 0x4c 0x69 0x74 0x65 0x20 0x66 0x6f 0x72 0x6d 0x61 0x74 0x20 0x33 0x00 which when read as UTF-8 encoded text reads SQLite format 3 followed by a nul-terminator byte Other significant values at offsets within the database header are as follows Offset 16 2 bytes 32 bit integer read big endian Page Size Offset 28 4 bytes 32 bit integer read big endian The logical size of the database in pages which is only populated when the database was last written by SQLite version 370 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 Offset 32 4 bytes 32 bit integer read big endian Page number of first freelist trunk page Offset 36 4 bytes 32 bit integer read big endian Total number of freelist pages including freelist trunk pages Offset 52 4 bytes 32 bit integer read big endian 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 B-Tree pages The SQLiteorg file format notes helpfully state that A large part of any SQLite database file 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 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 page 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 pages, with the exception of page 1, the header starts at the beginning of the page at offset 0 On page 1 the header starts at offset 100 The first byte of all B-Tree page headers is a flag field, each flag is detailed as follows 0x02 flag indicating index B-Tree internal node 0x0A flag indicating index B-Tree leaf node 0x05 flag indicating table B-Tree internal node 0x0D flag indicating table B-Tree leaf node These flags therefore allow us to potentially identify B-Tree pages of all types by examining the first byte of each page to see if it is either 0x02, 0x0A, 0x05 or 0x0D The B-Tree page header also contains some other potentially useful values offsets from start of page Offset 1 2 bytes 32 bit integer read big endian Byte offset of first block of free space on this page 0 if no free blocks Offset 3 2 bytes 32 bit integer read big endian Number of entries cells on this page Offset 5 2 bytes 32 bit integer read big endian 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 Freelist pages Once again the SQLiteorg file format notes help us out 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 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 The operation of the freelists might be better understood by a quick forensic examination of them IMAGE 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 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 offset page number-1 x page size which in this case is 61-1 x 4096 245760 IMAGE 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 0x00 0x00 0x00 0x45 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 Pointer map pages 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 Locking Page The locking page is the database page that starts at byte offset 230 1,073,741,824 and always remains unused ie all zeros Most databases will not be big enough 1GB to require a locking page Overflow pages Once again the SQLiteorg file format notes help us out 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 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 So how does this help with carving SQLite databases then We can use the database header and the first byte value of each page thereafter to determine whether the data within each page size block is valid So from a carving perspective we can identify the first page with the database header, calculate the page size, read the next page and validate the first byte and so on until the first byte validation fails This essentially is what Rasmus Riis's Chrome SQlite db finder v14 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 page, other than the first page, for the values 13,10, 2, 5 or 0 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 page 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 SMSdb database are Rasmus's enscript also carries out a test of the two bytes at offset 100 within the first database page 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 0x0D 0x0F or 0x0F 0x0D or 0x0D 0x03 I am not sure what Rasmus had in mind for the second value 3853 which is 0x0D 0x0F 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 page The first page 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 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 fingerprint for each database type I have not collected enough test data to be certain about this yet IMAGE With regards to Rasmus's enscript 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 SQLitedb I am in touch with my programming friends to create a script that can carve and identify SQLite databases from the fingerprint discussed above and also include a greater amount of error checking Other stuff of note When you examine data within SQLite databases have you noticed that most of the meaningful stuff is bunched up at the end of each page The SQLiteorg file format notes help us out here 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 To Do 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 Thanks to Rasmus Riis for sharing his enscript and to Chris Vaughan for his help in firming up some of the theory References http wwwsqliteorg fileformathtml http wwwsqliteorg fileformat2html http wwwsqliteorg requirementshtml http wwwsqliteorg hlr30000html https supportguidancesoftwarecom forum downloadsphp do file id 1116 http://www.secuobs.com/revue/news/301218.shtmlhttp://www.secuobs.com/revue/news/301218.shtml Secuobs.com : 2011-01-04 18:33:04 - Forensics from the sausage factory - 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 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 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 eg pst, dbx etc Encase names the msg file either by its subject or by some arbitrary description Inboxdbx-0msg, Inboxdbx-1msg 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 To address this problem Oliver has written an enscript to export selected emails to msg along with a report detailing their provenance IMAGE 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 IMAGE As always if you would like a copy please email me Richard Drinkwater http://www.secuobs.com/revue/news/275729.shtmlhttp://www.secuobs.com/revue/news/275729.shtml Secuobs.com : 2010-11-09 01:50:32 - Forensics from the sausage factory - 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 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 IMAGE 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 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 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 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 VSPL understand the needs of LE computer forensic labs and most importantly have always been available to support me when required 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 Obviously there is a little bit more to it than that If you are interested in finding out more please let me know, http://www.secuobs.com/revue/news/263357.shtmlhttp://www.secuobs.com/revue/news/263357.shtml Secuobs.com : 2010-10-09 12:14:36 - Forensics from the sausage factory - FTK Imager has always been the crème de la crème of free forensic tools and now with the introduction of FTK Imager 3 it is even better Access Data have added some amazing functionality to this programs already extensive list of capabilities - in fact to steal a phrase - its almost magical and it is certainly available at an unbelievable price So what am I referring to 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 Release Notes This functionality is accessed via File Image Mounting IMAGE In this screen shot I have chosen to mount a drive from a Mac which includes a Bootcamp partition IMAGE 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 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 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 à la Encase VFS 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 FTK Imager 3 also introduces support for VXFS, ex FAT and EXT4 file systems As we sometimes say in England its the dogs http://www.secuobs.com/revue/news/255532.shtmlhttp://www.secuobs.com/revue/news/255532.shtml Secuobs.com : 2010-09-21 03:27:49 - Forensics from the sausage factory - This post includes a new method to recover USN Change Journal artefacts from unallocated some background information some commentary on benefitting from the existing work of Lance Mueller and Seth Nazzaro Background The examination of USN Change Journals is nothing new and was commented on as long ago as September 2008 in Lance Mueller's blog My interest was piqued more recently when Harlan Carvey discussed the python script written by Seth Nazzaro to parse these Journals 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 30 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 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 here 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 Lance Mueller's Enscript Lance's script 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 Seth Nazzaro's Python Script Seth wrote his script because he had difficulty in running the Enscript -possibly for the reasons described above I have described how to run the script in my earlier Python post 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 Recovering USN Change Journal Records from unallocated Regular readers will know that I am particularly keen in recovering file system and other data from unallocated I am pleased to see I am not alone 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 IMAGE It is possible to locate large numbers of deleted USN Change Journal Records in unallocated clusters There is a clear structure to them To carve these from unallocated I use my file carver of choice Blade I have created a Blade data recovery profile which recovered a very large number of records from my test data Profile Description UsnJrnl J records ModifiedDate 2010-07-14 08 32 57 Author Richard Drinkwater Version 1710195 Category NTFS artefacts Extension bin SectorBoundary False HeaderSignature x00 x00 x02 x00 x00 x00 HeaderIgnoreCase False HasLandmark True LandmarkSignature x00 x3c x00 LandmarkIgnoreCase False LandmarkLocation Static Byte Offset LandmarkOffset 57 HasFooter False Reverse False FooterIgnoreCase False FooterSignature x00 BytesToEOF 1 MaxByteLength 1024 MinByteLength 64 HasLengthMarker True UseNextFileSigAsEof False LengthMarkerRelativeOffset 0 LengthMarkerSize UInt32 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 LandmarkSignature x00 x3c x00 x2E x2E x00 al x00 vn x00 ik 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 IMAGE This can be achieved at the command prompt, folder by folder copy bin USNJRNL J 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 QCC 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 USNJRNL J files you can then run either script against them Please note the folder structure the enscript requires as referred to above 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 Given the potentially large number of records that are recoverable I found it sensible to run a restricted Blade Recovery profile for just the file types you are interested in eg avi and lnk Run John Douglas's concatexe across Blades output In Windows 7 use the search facility to locate each concatenated USNJRNL J file copy them all into one folder allowing Windows to rename the duplicates at the command prompt use a for loop to process them along the lines of for L pourcentsa in 1,1,40 do python UsnJrnl-24NOV09py -f UsnJrnl J pourcentsa outputpourcentsa -t or for L pourcentsa in 1,1,40 do python UsnJrnl-24NOV09py -f UsnJrnl J pourcentsa -s outputtsv or drag the concatenated files back into Encase as single files and process further with Lance's script References http wwwopensourceapplecom source ntfs ntfs-64 kext ntfs_usnjrnlh txt http wwwmicrosoftcom msj 0999 journal journalaspx http technetmicrosoftcom en-us library cc976808aspx http wapediamobi en USN_Journal http codegooglecom p parser-usnjrnl http wwwforensickbcom 2008 09 enscript-to-parse-usnjrnlhtml http://www.secuobs.com/revue/news/250065.shtmlhttp://www.secuobs.com/revue/news/250065.shtml Secuobs.com : 2010-09-21 03:27:49 - Forensics from the sausage factory - 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 Marrakesh Express floating around in my brain OK I know I've lost two thirds of my readership already - Crosby Stills and WHO This post, once I've overcome a touch of nostalgia, is about the use of compression by Microsoft in the Hiberfilsys 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 Matthieu Suiche I also know that functionality exists in Xways to decompress Hiberfilsys but until now this functionality was absent in Encase The reason Microsoft uses compression is to minimise the footprint of Hiberfilsys The compression seeks to reduce Hiberfilsys to about 75pourcents 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 x81 x81xpress Not all hiberfilsys files utilise this compression 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 Hiberfilsys is used to store the contents of memory when the computer concerned is hibernated and therefore potentially may contain Microsoft Notification Protocol messages relating to WLM conversation A fairly typical grep keyword used to find these traces is x20PF When run over a hiberfilsys containing xpress compression results may appear similar to the following screenshot IMAGE 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 IMAGE 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 hiberfilsys 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 GSI's download center Finding traces of MSNP is only one use, you can find indexdat contents, Limewire search terms and many other interesting artefacts in Hiberfilsys - happy searching References http wwwforensicswikiorg wiki Hiberfilsys http msdnmicrosoftcom en-us library ee915356 PROT13 aspx http://www.secuobs.com/revue/news/250064.shtmlhttp://www.secuobs.com/revue/news/250064.shtml Secuobs.com : 2010-07-23 16:28:48 - Forensics from the sausage factory - 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 First off we need to install and configure Python Download Python - I downloaded Python 27 Window X86-64 installer for my Windows 7 64 bit box Run the installer Right click on the Computer icon, select properties, select Advanced system settings and click on the Environment Variables button In the System Variables pane you will have a variable entitled Path, select it and click on edit Add to the entries already there C Python27 assuming you installed Python 27 to the default location 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 author's blog 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 analyzeMFT Download script by visiting http wwwintegriographycom and right clicking on the Downloaded Here link in the Downloads section for the source code and saving the download as a text file Once downloaded change the file extension to py Save it somewhere and then run IDLE installed with Python and open the analyzeMFTpy script Locate the words noGUI False and edit to read noGUI True and save To run open command prompt at prompt type Python C Path_to_the_script analyzeMFTpy -f U Path_to_your_extracted_or_mounted_MFT MFT -o MFT_parsed The above command runs the script against your extracted or mounted MFT and outputs the results to a file MFT_parsed Open MFT_parsed using the text import wizard in Excel selecting the text format for each column Thanks to David Kovar for making this script available USNJRNL J Parser This script can be downloaded at http codegooglecom p parser-usnjrnl To run open command prompt at prompt type Python C Path_to_the_script UsnJrnlpy -f U Path_to_your_extracted_or_mounted_USNJRNL J USNJRNL -o Output_file -c The above command runs the script against your extracted or mounted USNJRNL J and outputs the results to Output_filecsv Notes Typing at the command prompt Python path_to_scriptpy wil give some help about a scripts options For example Python UsnJrnlpy results in the output Usage UsnJrnlpy options Options -h, --help show this help message and exit -f INFILENAME, --infile INFILENAME input file name -o OUTFILENAME, --outfile OUTFILENAME output file name no extension -c, --csv create Comma-Separated Values Output File -t, --tsv create Tab-Separated Values Output File -s, --std write to stdout I have installed Python 27 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 http://www.secuobs.com/revue/news/243274.shtmlhttp://www.secuobs.com/revue/news/243274.shtml Secuobs.com : 2010-07-20 00:53:32 - Forensics from the sausage factory - 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 Digital Detective's Hstex 3 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 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 eg indexdats, 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 IMAGE 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 A bit of googling led me to page 42 of Forensic Implications of Windows Vista - Barrie Stewart which identified the structured data I had located as being part of Gatherer Transaction Log files created by the search indexer process of Windows Search These files have a filename in the format SystemIndexNtfyXgthr where the X is replaced by a decimal number and on a live Vista system can be found at the path C ProgramData Microsoft Search Data Applications Windows Projects SystemIndex These files have the words Microsoft Search Gatherer Transaction Log Format Version 49 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 USN Change Journal 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 the next blog post 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 Stewart 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 Stewart's test data Record Header 0x4D444D44 4 bytes Unknown variable data 12 bytes FILETIME Entry 8 bytes FILETIME Entry 8 bytes or a value of 0x 0100 00000000000000 Unknown variable data 12 bytes 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 Name and fullpath of file folder ASCII or Unicode -version dependant variable length 0x000000000000000000FFFFFFFF 13 bytes FILETIME Entry 8 bytes or a value of 0x 0100 00000000000000 0xFFFFFFFF 4 bytes FILETIME Entry 8 bytes or a value of 0x 0100 00000000000000 Unknown variable data 4 bytes Sequence or index number 1 byte stored as 8 bit integer Unknown variable data 15 bytes FILETIME Entry 8 bytes or a value of 0x 0100 00000000000000 FILETIME Entry 8 bytes or a value of 0x 0100 00000000000000 Unknown variable data 20 bytes 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 Cy4or 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 Timestamps 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 File Modified File Altered 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 1 It is worth reminding readers who are Encase users that Encase uses different terminology for the time stamps within the MFT - file modified is referred to as Last Written I think it likely that timestamps 1 and 2 are linked to the indexing function eg 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 IMAGE Example CSV output of Enscript click to enlarge - this image is not very clear -will try and improve it soon References Good citizenship when developing background services for Windows Vista - Microsoft Forensic Implications of Windows Vista - Barrie Stewart Forensic Artefacts Present in Microsoft Windows Desktop Search - John Douglas MSc Thesis Indexing Process in Windows Search - Microsoft MSDN 1 http msdnmicrosoftcom en-us library cc232038pourcents28PROT10pourcents29aspx http://www.secuobs.com/revue/news/241875.shtmlhttp://www.secuobs.com/revue/news/241875.shtml Secuobs.com : 2010-06-29 00:13:08 - Forensics from the sausage factory - 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 Recovering Safari browser history from unallocated deals with history Safari browser cache -examination of Cachedb deals with the cache Never mind the cookies lets carve the crumbs - Safari Cookie stuff looks at Cookies Safari History - spotlight webhistory artefacts examines Spotlight snapshots of web pages accessed with Safari 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 Library Safari LastSessionplist Used to store details of the last browser session allowing a user to select Reopen All Windows from Last Session from the safari history menu Library Safari WebpageIconsdb Library Safari Iconsdb Used to store the associations between websites and their favicons Library Safari TopSitesplist Library PubSub Feeds xml Library Caches comappleSafari Webpage Previews TopSites is a gallery of recently visited web sites The binary TopSitesplist details the websites featured in this gallery The image representing each webpage is stored within the Webpage Previews folder This folder also stores any Quicklook representation of a webpage, for example when managing Bookmarks or reviewing History 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 PubSub Feeds are connected with the monitoring Library Safari Downloadsplist An xml plist the contents of which are self explanatory Library Caches Metadata Safari History tracked filenamesplist A binary plist that may be connected to Safari spotlight web history artefacts http://www.secuobs.com/revue/news/235844.shtmlhttp://www.secuobs.com/revue/news/235844.shtml Secuobs.com : 2010-06-22 11:44:49 - Forensics from the sausage factory - Safari versions 3, 4 and 5 amalgamates Cookie data into one large file Cookiesplist stored at the path Library Cookies 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 As is becoming a recurring theme with my Safari examinations I have turned to Blade to carve out Safari Cookie data from unallocated The Cookieplist consists of an array of dictionary objects IMAGE Using Apple's Property List Editor it can be seen that this Cookieplist has an array of 7074 Dictionary objects Each Dictionary object is a Cookie in its own right IMAGE Looking at the underlying XML you can see how each dictionary object is structured 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 These dictionary objects are fragments of the cookieplist - hence the crumb reference in the title -after all fragments of cookies are clearly crumbs 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 Profile Description Safari Cookie records ModifiedDate 2010-06-17 06 33 30 Author Richard Drinkwater Version 1310168 Category Safari artefacts Extension plist SectorBoundary False 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 HeaderIgnoreCase False HasLandmark True LandmarkSignature Expires LandmarkIgnoreCase False LandmarkLocation Floating LandmarkOffset 0 HasFooter True Reverse False FooterIgnoreCase False FooterSignature x3C x2F x73 x74 x72 x69 x6E x67 x3E x0A x09 x3C x2F x64 x69 x63 x74 x3E x0A BytesToEOF 19 MaxByteLength 9728 MinByteLength 200 HasLengthMarker False UseNextFileSigAsEof True LengthMarkerRelativeOffset 0 LengthMarkerSize UInt16 Processing the Carved Files 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 Option 1 Drag output into Encase as single files Run Encase Comprehensive Internet History search View results on records tab 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 cookieplists, 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 Option 2 Concatenate the contents of each output folder by navigating to the folder at the command prompt and executing the command copy plist combinedplist With a text editor add the plist header and array tag at the beginning of combinedplist and the closing plist and array tags at the end Make sure the formatting of combinedplist looks OK with a text editor Process combinedplist with Jake Cunningham's safari cookie plist parser The utility is run from the command prompt using a command in the form path to Safari_cookiesexe path to combinedplist cookiestxt This parses the plist into the file cookiestxt 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 there is probably a far more elegant way to do this BTW open cookiestxt in a hex editor PSPad Hex and delete all the carriage returns 0D0A I then find the string Path 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 Domain, Name, Created, Expires and Value and replace each in turn with the same string prefaced with eg Domain, Name etc etc I then use Excel's text import wizard to import the edited cookiestxt setting the delimiter to the pipe symbol only This results in each row relating to one cookie You can then utilise Excel's very powerful duplicate removal tool Both the Mac and Windows versions work OK and the utility converts the CFAbsolute formatted cookie created timestamp http://www.secuobs.com/revue/news/233768.shtmlhttp://www.secuobs.com/revue/news/233768.shtml Secuobs.com : 2010-06-15 13:24:26 - Forensics from the sausage factory - 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 These files filenames are in the format URLwebhistory Their internal structure is that of a binary plist with three strings to each record Full Page Text, Name and URL They are stored at the path Library Caches Metadata Safari History The file created date of these files represents the time that the URL was first visited since History was last cleared The file modified date represents the time that the URL was last visited 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 historyplist and cachedb files Recovery from Unallocated 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 - Digital Detective's Blade I wrote an appropriate Data Recovery Profile which I will happily share with you upon request IMAGE Click on image for larger version 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 Investigation of Live and Recovered Spotlight Webhistory Files using Encase 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 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 Plist Parser v35 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 IMAGE Click on image for larger version Miscellaneous Information in relation to the webhistory file format 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 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 Apple's release of the binary plist format 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 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 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 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 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 IMAGE Example file format Click on image for larger version References http opensourceapplecom source CF CF-550 CFBinaryPListc http developerapplecom mac library documentation Cocoa Conceptual PropertyLists AboutPropertyLists AboutPropertyListshtml apple_ref doc uid 10000048i-CH3-SW2 http://www.secuobs.com/revue/news/231590.shtmlhttp://www.secuobs.com/revue/news/231590.shtml Secuobs.com : 2010-06-08 22:17:33 - Forensics from the sausage factory - Following on from my post about Safari browser history I want to touch upon Safari cache My suspect is running Mac OSX 1056 Leopard and Safari 321 This version stores browser cache in an sqlite3 database Users User_Name Library Caches comappleSafari Cachedb Earlier versions of Version 3 and Version 1 and 2 store cache in a different format, and or a different place The Episode 3 Shownotes 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 Cachedb file so another method is required Safari Cachedb basics What follows I believe relates to both version 3 and 4 of Safari running in Mac OSX 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 cachedb 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 Two tables are of particular interest cfurl_cache_blob_data cfurl_cache_response cfurl_cache_blob_data contains one very notable field and a number of slightly less useful ones The notable field is receiver_data which is used to store the cached item itself eg cached jpgs, gifs, pngs, html et al as a BLOB A BLOB is a Binary Large OBject Two other fields request_object and response_object contain information relating to the http request response cycle also stored as a BLOB which when examined further are in fact xml plists The entry_ID 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 cfurl_cache_response contains two notable fields - request_key and time_stamp The request_key field is used to contain the URL of the cached item The time_stamp field is used to store the time the item was cached The entry_ID 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 In a nutshell cfurl_cache_blob_data contains the cached item and cfurl_cache_response contains metadata about the cached item Safari cachedb examination methods I would like to share three different methods using SQL queries and a few different tools Safari cachedb examination methods - contents quick and dirty Safari cachedb examination methods - metadata quick and dirty Safari cachedb examination methods - contents and metadata Safari cachedb examination methods - contents quick and dirty 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 cachedb as opposed to the associated meta data I can not recommend any application more highly than File Juicer 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 IMAGE 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 per se but the developer has at least considered the possibility that it may be used as such If using a Mac is not an option a Windows app SQL Image Viewer may suffice with the caveat that I have not actually tested this app Safari cachedb examination methods - metadata quick and dirty 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 ie one or the other to carry out a quick review of meta data Method A using Sqlite3 itself http wwwsqliteorg downloadhtml scroll down to the Precompiled Binaries for Windows section extract your cachedb file into a folder copy sqlite3exe into the same folder to cut down on typing paths etc launch a command prompt and navigate to your chosen folder Type sqlite3 cachedb then at the sqlite prompt type output Cache_metadatatxt this directs any further output to the file Cache_metadatatxt at sqlite prompt type Select time_stamp, request_key from cfurl_cache_response don't forget the semi colon allow a moment or three for the query to complete the output of it's results Launch Microsoft Excel and start the Text Import Wizard selecting step by step delimited data, set the delimiters to Other pipe symbol and set the Column data format to Text Click on Finish then OK and bobs your uncle IMAGE Click image to view full size Method B using SQLite Database Browser as a viewer in Encase from your Encase case send the Cachedb to SQLite Database Browser on the Execute SQL tab type in the SQL string field enter Select time_stamp, request_key from cfurl_cache_response Review results in the Data returned pane Or from your Encase case send the Cachedb to SQLite Database Browser File Export Table as CSV file Select the cfurl_cache_response Table name Open exported CSV in Excel and adjust time_stamp column formatting a custom date format is required to display seconds Safari cachedb examination methods - contents and metadata 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 SQLite2009 Pro Enterprise Manager 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 Once you have launched the program open your extracted Cachedb file In the Query box type or copy and paste all in one go SELECT cfurl_cache_blob_dataentry_ID,cfurl_cache_blob_datareceiver_data, cfurl_cache_responserequest_key,cfurl_cache_responsetime_stamp FROM cfurl_cache_blob_data, cfurl_cache_response WHERE cfurl_cache_blob_dataentry_ID cfurl_cache_responseentry_ID Then key F5 to execute the query This will populate the results tab with the results To view the cached object BLOB data in the receiver_data field highlight the record of interest with your mouse but don't click on BLOB in the receiver_data field This will populate the hex viewer bottom left and the BLOB viewer bottom right To view a full sized version of a cached image click with your mouse on BLOB in the receiver_data field which launches a separate viewing window IMAGE Click on image to view full size References SQLite Database File Format Sindrome weblog - Extracting data from Apple Safari's cache http wwwdevxcom dbzone Article 17403 1954 Inside the Core - The Macintosh and Apple Device Forensics Podcast Episode 3 Shownotes Define relationships between database tables -Techrepublic http://www.secuobs.com/revue/news/229700.shtmlhttp://www.secuobs.com/revue/news/229700.shtml Secuobs.com : 2010-06-06 16:36:24 - Forensics from the sausage factory - One of my cases involves the examination of an Apple Mac running Mac OSX 1056 Leopard The primary web browser in use is Safari version 321 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 Library Safari Historyplist 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 wwwforensicwikicom but at the time of writing this resource is still offline One of the best file carvers around is Blade and I decided to use it to recover the deleted Historyplists 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 write your own profiles and share them with others In conversation I had found out that Craig Wilson had written a Safari historyplist 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 IMAGE Click image for a full size version 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 Historyplist files I then loaded the recovered plist files into Netanalysis 151 resulting in over 300,000 internet history records to review Cool http://www.secuobs.com/revue/news/228976.shtmlhttp://www.secuobs.com/revue/news/228976.shtml Secuobs.com : 2010-05-27 13:06:40 - Forensics from the sausage factory - 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 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 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 Prefetch 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 Yogesh Khatri at 42llc 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 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 IMAGE Bookmarking Last Execution Time and Date IMAGE Bookmarking number of times the application was run If you have a number of prefetch files to analyse or you wish to corroborate your findings you could try the Mitec Windows File Analyzer program or run an enscript Guidance Software's download center has two enscripts that fit the bill PfDumpEnpack and Prefetch File Analysis Pfdump outputs to the console and the Prefetch File Analysis enscript outputs to bookmarks UserAssist 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 NTUSERDAT 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 download center 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 References https 42llcnet indexphp option com_myblog show Prefetch-Files-Revisitedhtml Itemid 39 http enwikipediaorg wiki Prefetcher http membersrushmorecom jsky id14html http membersrushmorecom jsky id37html http jessekornblumcom presentations dodcc08-2pdf http://www.secuobs.com/revue/news/226235.shtmlhttp://www.secuobs.com/revue/news/226235.shtml Secuobs.com : 2010-05-11 08:59:35 - Forensics from the sausage factory - Many C4P users experience problems when importing bookmarks back into Encase from C4P A common problem is that files bookmarked in Unallocated Clusters don't match up to actual picture data Almost always the cause of this problem is that the user has run the Recovered Folders process in Encase after running the C4P Graphics Extractor enscript thus altering the amount of unallocated clusters as calculated by Encase Trevor has a two page pdf on the C4P website addressing all the potential issues I have noticed another problem A large number of my notable files are in Lost Files Lost Files in Encase on an NTFS volume are files that have an MFT entry but their parent folder has been deleted It is possible to have a number of files in the virtual Lost Files folder that have the same file name and path In my current case where I have duplicate file names in Lost Files the C4P Import enscript has not always bookmarked the correct file, bookmarking another file with the same name and path instead This is sometimes further complicated by the incorrect file being deleted and overwritten The symptoms of this problem are easy to detect Viewing your C4P import within the Encase bookmarks tab in gallery view results in a number of pictures not being displayed When checking the bottom pane in text view you see that the bookmarked data for the non displaying pictures does not relate to a picture Alternatively the picture you see does not relate to the C4P category it should be To review this I am currently selecting blue ticking all non displaying pictures or wrongly bookmarked pictures and then tagging these selected files Having done this in Entries view I am sorting by selection blue tick then highlighting a blue ticked file, then sorting by name This brings all the other files with the same name together in Entries view I am then checking the others to find the file that was meant to be bookmarked The underlying problem is a small bug in the C4P Import v2 enscript Trevor has now kindly fixed it for me and will no doubt circulate the revised script However in the meantime to fix the script Find the following file in the import script folder include ProcessReportClassEnScript In there, find the following function EntryClass FindByFullPath ImportRecordClass irc, CaseClass c It s a short function, only eight lines highlight them, and replace with the following EntryClass FindByFullPath ImportRecordClass irc, CaseClass c EntryClass e cEntryRoot e eFind ircDeviceName ircPath if e if ePhysicalLocation ircPhysicalLocation return e else return null else return null Save and update HTH someone http://www.secuobs.com/revue/news/220846.shtmlhttp://www.secuobs.com/revue/news/220846.shtml Secuobs.com : 2010-04-13 17:51:56 - Forensics from the sausage factory - Without further ado this post will build upon Volume Shadow Copy Forensics - the Robocopy method Part 1 In part one we looked at using Robocopy to extract data from a single shadow copy at a time We will now look at a method to extract data from a range of shadow copies in one go I will also cover some slightly more advanced options What are we going to need For what follows we will need a Windows 7 box real or a VM , Encase with the PDE module and some storage space formatted NTFS Robocopy is pre-installed within Windows 7 Method You will already have an Encase image of the drive you wish to investigate When this is loaded up into an Encase case you need to gather some information in respect to the shadow copies you wish to investigate further You will need to note the File Creation dates and if you wish to be more precise establish the Shadow Copy IDs stored at File Offset 144 for 16 bytes - bookmark as a GUID in Encase Next you will have to mount the volume containing the shadow copies as an emulated disk using the Encase PDE module with caching enabled On my box the mounted volume was allocated the drive letter J I am using a Windows 7 box - if you are using a Windows 7 VM add the PDE mounted disk to the VM as an additional hard disk Then on your box or in the VM Run a Command Prompt as Administrator and type the command substituting J for the drive letter allocated to your mounted volume and G Shadows with the path of your export directory vssadmin list shadows for J G Shadows list_of_shadow_copiestxt This will create a text file containing a list of available shadow copies From the list we can identify a range of shadow copies that we wish to investigate further We now need to create symbolic links to them using the command for l pourcentsi in 22,1,24 do mklink d c Users Richard Desktop Symbolic SCpourcentsi GLOBALROOT Device HarddiskVolumeShadowCopypourcentsi note there is not a space after the This command will create symbolic links for all shadow copy IDs starting at 22 up to 24 Obviously vary the 22,1,24 part to suit - 22 is the start, 1 increments by 1 and 24 is the end value The symbolic links in this example are being created in a folder C Users Richard Desktop Symbolic that I have allocated for this purpose Many walk throughs, including ones I have prepared, often create the symbolic links at the root of C Vista and Windows 7 do not like files being stored there so I think it is better practise to create the symbolic links in a user area OR If you do not wish to process a range of shadow copies but need to process more than one or two you can instead use the command for pourcentsi in 18 20 22 do mklink d c Users Richard Desktop Symbolic SCpourcentsi GLOBALROOT Device HarddiskVolumeShadowCopypourcentsi note there is not a space after the This command process only shadow copy IDs 18, 20 and 22 Next we will run robocopy over the range of shadow copies we have selected for l pourcentsi in 22,1,24 do robocopy c Users Richard Desktop Symbolic SCpourcentsi Users G Shadows SCpourcentsi jpg txt S COPY DAT XJ w 0 r 0 LOG G Shadows Robocopy_log_SCpourcentsitxt OR for pourcentsi in 18 20 22 do robocopy c Users Richard Desktop Symbolic SCpourcentsi Users G Shadows SCpourcentsi jpg txt S COPY DAT XJ w 0 r 0 LOG G Shadows Robocopy_log_SCpourcentsitxt where you are interested in just specific shadow copies IMAGE This command will create output folders named after each selected shadow copy along with a log of what has been copied These items are being stored within an export folder prepared for the purpose In this example I have drilled down to just the Users folder and copied out only jpg and txt files Please see Part 1 for a detailed explanation of the options used in the command The output folders can be dragged into Encase as single files All paths and timestamps have been preserved Network Shares instead of Symbolic Links alternative In part 1 I touched upon possible permission and copying errors Troy Larson from Microsoft commented that creating shares instead of symbolic links may overcome some issues So as an alternative the command for l pourcentsi in 22,1,24 do net share SCpourcentsi HarddiskVolumeShadowCopypourcentsi will create network shares entitled SC22, SC23 and SC24 for the shadow copy IDs 22-24 We can now use robocopy to copy data out of these shares for l pourcentsi in 22,1,24 do robocopy localhost SCpourcentsi Users G Shadows SCpourcentsi jpg txt S COPY DAT XJ w 0 r 0 LOG G Shadows Robocopy_log_SCpourcentsitxt In this example I am accessing the shares on the same box hence localhost but of course you can run this across a network The resulting data is as before Incorrect Function You may run into what I think is a permission related error - clicking on the symbolic link results in IMAGE or you see 2010 04 12 15 25 28 ERROR 1 0x00000001 Accessing Source Directory c Users Richard Desktop Symbolic SC22 Users Incorrect function in your log file I have tried myriad ways to overcome this - trying to take ownership of the Shadow Copies using cacls, icacls and everything else but the kitchen sink However I did eventually find a workaround In Volume Shadow Copy Forensics cannot see the wood for the trees I discussed imaging shadow copies using George Garner's Forensic Acquisition Utility This utility appears not to have this issue so the command for l pourcentsi in 22,1,24 do dd if HarddiskVolumeShadowCopypourcentsi of G Shadows pourcentsiimg bs 512 count 1 --localwrt will image just one sector of each shadow copy in our range This takes just a few seconds Then after imaging make your symbolic links or network shares The Incorrect Function issue is overcome Don't ask me why Dealing with the storage issues If you want to copy substantial amounts out of a large number of shadow copies you are faced with the problem of where you can store it In Volume Shadow Copy Forensics cannot see the wood for the trees I observed that there is considerable duplication of files in each shadow copy I have found that a utility like Duplicate and Same Files Searcher can be useful This utility can search across your export folders and identify duplicates You can then opt to retain the first file and then create hard links for all the duplicate files This utility can also move duplicate files, thus allowing you to focus on just the unique files References Windows 7 Current Events in the World of Windows Forensics Harlen Carvey, Troy Larson Reliably recovering evidential data from Volume Shadow Copies in Windows Vista and Windows 7 QCC http://www.secuobs.com/revue/news/211596.shtmlhttp://www.secuobs.com/revue/news/211596.shtml Secuobs.com : 2010-04-06 18:39:42 - Forensics from the sausage factory - There is always more than one way to skin a cat and so I make no apologies for discussing another approach to processing volume shadow copies This approach - I'll call it the Robocopy method - has been researched and developed by the chaps over at QCC, John Douglas, Gary Evans and James Crabtree and they have kindly let me crib from their notes This post is Part 1 - I have simplified QCC's approach but have also removed some functionality In Part 2 I will expand on the simplified approach and add back in some functionality Robocopy is a robust file copying utility developed by Microsoft This method allows us to copy out folders and files of interest from any notable shadow copies The process will preserve folder and file paths and timestamps The key advantages are that it is efficient -both in storage and speed This blog post complements my previous posts Vista Volume Shadow Copy issues and Volume Shadow Copy Forensics cannot see the wood for the trees and the method documented below is similar in the early stages What are we going to need For what follows we will need a Windows 7 box real or a VM , Encase with the PDE module and some storage space formatted NTFS Robocopy is pre-installed within Windows 7 Method You will already have an Encase image of the drive you wish to investigate When this is loaded up into an Encase case you need to gather some information in respect to the shadow copies you wish to investigate further You will need to note the File Creation date and if you wish to be more precise establish the Shadow Copy ID stored at File Offset 144 for 16 bytes - bookmark as a GUID in Encase Next you will have to mount the volume containing the shadow copies as an emulated disk using the Encase PDE module On my box the mounted volume was allocated the drive letter I I am using a Windows 7 box - if you are using a Windows 7 VM add the PDE mounted disk to the VM as an additional hard disk Then on your box or in the VM Run a Command Prompt as Administrator and type the command substituting I for the drive letter allocated to your mounted volume vssadmin list shadows for I This will result in a list of all available shadow copies on the selected volume vssadmin 11 - Volume Shadow Copy Service administrative command-line tool C Copyright 2001-2005 Microsoft Corp Contents of shadow copy set ID 2202d8a9-1326-4254-9818-252ece858b17 Contained 1 shadow copies at creation time 10 12 2009 14 41 25 Shadow Copy ID ad2e71d0-48d6-44b9-9715-f5ff6b5a5643 Original Volume I Volume 34e5a98a-1a1d-11df-a259-00236cb6de69 Shadow Copy Volume GLOBALROOT Device HarddiskVolumeShadowCopy5 Originating Machine Richard-MBP-Vis Service Machine Richard-MBP-Vis Provider 'Microsoft Software Shadow Copy provider 10' Type ClientAccessibleWriters Attributes Persistent, Client-accessible, No auto release, Differentia l, Auto recovered Contents of shadow copy set ID e13bb9d9-c522-422b-b92a-37f6d12363d9 Contained 1 shadow copies at creation time 15 12 2009 12 17 37 Shadow Copy ID d0e1c613-7892-47e1-9b7e-f638adac9d16 Original Volume I Volume 34e5a98a-1a1d-11df-a259-00236cb6de69 Shadow Copy Volume GLOBALROOT Device HarddiskVolumeShadowCopy6 Originating Machine Richard-MBP-Vis Service Machine Richard-MBP-Vis Provider 'Microsoft Software Shadow Copy provider 10' Type ClientAccessibleWriters Attributes Persistent, Client-accessible, No auto release, Differentia l, Auto recovered Marry up your bookmarked GUID to the Shadow Copy ID number to identify the Shadow Copy Volume you wish to process The next step is to create a symbolic link to the selected shadow copy ShadowCopy6 in this example by typing the command mklink d C shadow_copy6 GLOBALROOT Device HarddiskVolumeShadowCopy6 which results in the output symbolic link created for C shadow_copy6 GLOBALROOT Device Harddisk VolumeShadowCopy6 We are now going to use robocopy to copy out data from the mounted shadow copy - for this example I have created a folder called SC6 on my export volume The command I used for this example is robocopy C shadow_copy6 Users Richard G SC6 S XJ COPY DAT NFL NDL w 0 r 0 This results in robocopy outputting a Job Header to the console --------------------------------------------------------------------------- ROBOCOPY Robust File Copy for Windows --------------------------------------------------------------------------- Started Mon Apr 05 11 23 18 2010 Source C shadow_copy6 Users Richard Dest G SC6 Files Options NDL NFL S COPY DAT XJ R 0 W 0 --------------------------------------------------------------------------- The header usefully sums up what I have asked robocopy to do I am copying only the Richard user profile Users Richard to my export folder SC6 indicates that I am copying all files NDL suppresses directory listings to the console NFL suppresses file listings to the console S copies the source folder and all sub folders and files COPY DAT copies data, attributes and timestamps XJ exclude junction points R 0 number of retries on failed copies in other words -do not re try W 0 wait between retries Nothing much happens at the command prompt now unless a failed file copy is encountered when you will receive output to the console similar to 2010 04 06 11 24 48 ERROR 5 0x00000005 Copying File C shadow_copy6 Users Rich ard AppData Local Temp DFA2EDtmp Access is denied When the copying is completed a summary is outputted to the console IMAGE It can be seen that 17 directories have been skipped This means they have not been copied -probably because of permission issues Also notable is the copying speed which is much quicker than imaging The output folder now contains a copy of the Richard users profile Drag the contents of the export folder into Encase which processes the contents as single files You may wish to create a logical evidence file of these single files Alternative Robocopy Configuration As inferred from the Job Header above it is possible to take a fairly granular approach to what is copied out of your shadow copy For example the command robocopy C shadow_copy6 Users G SC6 jpg bmp png S XJ COPY DAT NFL NDL w 0 r 0 will copy out all jpg, bmp and png files from all User profiles With reference to the two examples in this post and the robocopy manual it is possible to configure the copy operation in many different ways For example you could just copy files that have timestamps in a particular range or files that are greater than a particular size Incorrect Function If you play with VSCs often you will run into this rather helpful Microsoft error message Tips to overcome it in Part 2 References Windows Vista 7 Recovering evidential data from Volume Shadow Copies John Douglas http technetmicrosoftcom en-gb library cc733145 WS10 aspx http blogssansorg computer-forensics 2009 01 08 robocopy- -a-computer-forensics-tool http 42llcnet indexphp option com_myblog task tag category robocopy Itemid 39 http://www.secuobs.com/revue/news/209349.shtmlhttp://www.secuobs.com/revue/news/209349.shtml Secuobs.com : 2010-03-22 20:16:21 - Forensics from the sausage factory - My digital Life of Grime case and another ongoing case have caused me to look more closely at the tools we use to analyse internet history Life of Grime's suspect had a penchant for the Flock browser and the other ongoing case involves Firefox 301 running on an Apple iBook The version of Flock in use is built on Firefox 3 also It seems to me that I am seeing Firefox as the browser of choice in the majority of my cases I know that most available statistics still put Internet Explorer in top spot but I still maintain Firefox has overtaken IE in my cases Certainly Firefox is worryingly by far the most popular browser used to read this blog Now as far as the data we think of as internet history is concerned, Firefox 3xx stores this data in a Sqlite database, placessqlite and sometimes additionally placessqlite-journal However in the wider sense internet history can also be determined from the Firefox cache because the page elements stored there contain each elements URL and associated times and dates Firefox stores it's cache in a folder entitled Cache within the xxxxxxxxdefault folder it is possible for a user to have more than one profile -so there may be other profile names not having the word default appended Cached items may be stored in a file by itself albeit renamed without a file extension or more often within cache block files eg -CACHE_001_ These cache block files can contain many cached items and therefore an index file is needed to record where an item is stored in the cache This index is called a cache map and is the file _CACHE_MAP_ Many of us have made use of a number of free utilities to examine Firefox 3 internet history These tools have become popular due to our mainstream, paid for, tools falling a little behind the curve and not supporting Firefox 3 These free utilities include http wwwfirefoxforensicscom http forensic-softwarecouk foxanalysisaspx http wwwmachor-softwarecom firefox_forensics http wwwnirsoftnet web_browser_toolshtml http wwwwoanycouk firefoxforensics http manuelsantandername wbfhtml All bar the Nirsoft tool can not parse any data out of Firefox cache Now for me that is a problem -not necessarily with the tools, but with the methodology I am going to use in a production line forensics environment I know there are other approaches -substituting the suspects profile into a test installation of Firefox for example but ideally I would prefer a one stop shop approach Regular readers will know that I work in an Encase shop and the Encase 615 comprehensive internet search will parse out live Firefox records from cache However in both the cases I am working on now, the cache map file is zeroed out In this situation Encase does not parse records still recorded within the cache block files and for that matter neither does the Nirsoft utility Which brings me to NetAnalysis As our more experienced readers will know NetAnalysis is the industry standard, tried and tested tool for the analysis of browser history and cache, particularly Internet Explorer history and cache NetAnalysis has always supported other browser artefacts but until now not Firefox version 3 NetAnalysis 150 and the associated program HstEx 3 now support Firefox 3 and then some In both my cases I have copied out the profile folders and quickly added them to a NetAnalysis workspace using the Open all history from folder option Because the cache map file is empty the cache is effectively deleted which is where HstEx 3 comes in HstEx 3 is a deleted history record extractor which can locate deleted records from physical disks, raw images and new to this version, directly from Encase evidence files In both my cases HstEx 3 was able to parse records from the cache block files that none of my other tools, including Encase 615, could do The advantage of being able to run HstEx 3 directly over Encase evidence files can not be over stated By running multiple sessions of Hstex 3, productivity can be considerably enhanced and at the same time freeing up image mounting tools for other uses NetAnalysis 150 also introduces many other new features -probably the headline one being the significantly enhanced cached web page rebuilding feature This is very cool Simply load in your suspects browser cache, press F6 and the workspace filters cached webpages that can be rebuilt Double clicking on them displays the page in a viewer and within an export folder the underlying html and associated page elements can be found Each rebuilt page folder can be copied for use in an html report for example I can't do this feature justice here but a Digital Detective knowledge base article covers it in more detail Other enhancements include the provision of an extensive audit log I think this facility is anticipating the tightening of regulation here in the UK with the advent of the Forensic Science Regulator More immediately it allows the creation of cracking contemp notes As a final thought, we all love free tools, many of them written by Harlan Carvey, Mark Woan, Tim Coakley and others we know and respect But we do need to be careful - one or two of the free tools I have referred to above have been written by people who, for whatever reason, have had to obfuscate their identity I do not doubt any of these tools, but what if a new tool was released that extracted data that none of our current tools could If we do not know who is behind it how do we know that the said tool was not on a certain date in the future going to scour our forensic network and modify all the Encase evidence files it came across As I said at the start you generally get what you pay for Till next time http://www.secuobs.com/revue/news/204086.shtmlhttp://www.secuobs.com/revue/news/204086.shtml Secuobs.com : 2010-03-21 15:23:47 - Forensics from the sausage factory - After writing that title I am wondering if I wouldn't be better employed writing crossword clues Back at the sausage factory I am bogged down investigating a digital Life of Grime You probably have done a case like it - there are several hard drives in the suspect's box all with multiple partitions Every nook and cranny is stuffed with IPoC and IVoC in a semi organised way Almost as if all the material was neatly stored at one time until my suspect got lazy and started storing stuff on the floor, in the hall, under the table, that sort of thing There are new folders after new folders -you don't see a New Folder 13 everyday Not content with filling up his hard drives my suspect had also felt the need to back his stuff up to CD-R or DVD Repeatedly The sheer quantity of files and folders in this case presents many problems and I thought I would share a few of them with you Most of the problems are linked to pictures, that is the vast quantity of pictures, all of which have to be categorised and counted As many of my readers will know in a case like this C4P is an essential tool going off at a tangent -googling C4P led to the discovery that c4p dot com is an online community for swingers - and now having said that we better watch out for some dodgy google ads appearing to the right - but hey they might improve my minuscule return from them - C4P stores the results of categorisation, whilst the case is being worked on, in an Access database that has a 2GB file size limit Now depending on how deeply your MDP folder is buried within your case folder structure this equates to about 19 million picture files A long standing problem has been that if the c4p graphics extractor enscript carves out more than about 19 million picture files C4P itself would fail to create a case, due to the underlying Access database maxing out In this case well over 21 million images were carved from the optical media alone and I was pleased to discover that C4P version 401 at least dealt with the maxing out issue fairly gracefully by creating a c4p4 file and then a second c4p4 file for the overspill Case creation failed but I was subsequently able to create a new case by opening the double clicking on the first c4p4 file, which is associated with C4P Doing this gave me a case with exactly 1,900,000 pictures which when viewed pragmatically is better than starting again It is clear that the Access database problem will become more of a problem as main stream hard disks become bigger and bigger and I was pleased to discover that a beta version 403 of C4P is available that utilises an SQLite database and whilst at it, runs happily on 64 bit boxes This version does not limit the number of pictures you can have in one case In a case like this another C4P bugbear also rears its ugly head The latest C4P graphics extractor enscript 403 carves out embedded thumbnails within jpgs, so for every picture file potentially you may have three carved images- the original, a thumbnail and a preview image I am not sure why the latest script does this as a feature of earlier scripts was that it didn't carve embedded images to avoid duplication It is that word -duplication- that is the problem C4P will allow you to create a report directly from the program but if you need to compile statistics how many Level 1s, 2s etc the report will be inaccurate I do not use C4P for reporting and instead use the C4P Import enscript to bring back the C4P results into my Encase case Once in Encase, sorting the C4P bookmarks by file offset provides a good indicator of how many embedded images there are Luckily it is a fairly simple exercise to remove the duplicate bookmarking -simply selecting blue checking each category folder in turn and tagging selected files, and then from Entries view rebookmarking the files concerned will effectively sort out most duplication Obviously different considerations will apply to pictures embedded into files for other reasons Moving away from C4P another issue in this case is establishing where the pictures came from Obviously establishing which browsers are being used is a job that need doing and an Enscript that does just that has been written by Mark Woan over at Woanware The WebBrowserInformationFinder enscript outputs to the console enabling you to copy and paste into your contemporaneous notes -very neat Talking of contemp notes I use John Douglas's Case Notes - another very neat program Looking at the problem a little wider it is worth considering some other angles to this problem, the registry contains a few pointers too, Harlan Carvey's post Browser Stuff covers this in more detail As it turned out my suspect used Flock as his default browser This browser is built upon Firefox 3 and stores internet history and cache in a profile in the same way as Firefox In the XP box I was looking at the profile folder was stored at the path C Documents and Settings USER_NAME Application Data Flock Browser Profiles xxxxxxxxdefault I have analysed this with NetAnalysis 150 More on NetAnalysis, Firefox 3 and the tools available to analyse this browser's artefacts in my next post http://www.secuobs.com/revue/news/203807.shtmlhttp://www.secuobs.com/revue/news/203807.shtml Secuobs.com : 2010-02-20 00:52:50 - Forensics from the sausage factory - There has been a great deal written about volume shadow copy forensics lately, much of it very technical The purpose of this post is to provide some of this information in an abridged form and to document a methodology to investigate them that works for me I work in an Encase shop so much of what follows is tailored for Encase users It is a followup to my earlier post What is a Volume Shadow Copy It is a snapshot of a NTFS formatted volume Typically they are created every day or two in Vista and on a weekly basis in Windows 7 Both operating systems will also create volume shadow copies prior to the installation of new software including Windows updates The Volume Shadow Copy Service VSS monitors all the changes made to a volume from the time that a shadow copy was created until the creation of the next one For the purpose of monitoring a volume is divided into 16 kilobyte blocks When a block is about to be overwritten it is backed up in the shadow copy Only changed blocks are backed up If there is a requirement to revert to a snapshot the original blocks are restored, replacing the changed ones, in a sense reconstituting the volume back to its state when the snapshot was taken Certain versions of Vista and Windows 7 allow users to revert to previous versions of files and folders, not just at the volume level Where are Volume Shadow Copies stored In the System Volume Information folder stored at the root of each protected volume Why might I need to investigate the contents of a Volume Shadow Copy You might not, but I am seeing many cases now where the Shadow Copies containrelevantevidence For instance, during your IPOC cases the file finder or the C4P graphics extractor enscript or Blade have identified pictures within the shadow copy file which do not exist on the live volume At that stage you simply do not know for example, whether these pictures were part of a web page accidentally viewed and then immediately closed down, embedded within an unsolicitedemail message, or there as a result of the intended actions of your suspect Or you may have experienced cases where Encase lists many files as deleted and overwritten but that have very very dodgyfile namesThe following screenshot is from an Encase case which contains a live volume and images of two shadow copies of the same volume Four deleted and overwritten files are listed, the metadata of which has been recovered by Encase from the MFT on the live volume It can be seen that these files are intact within the shadow copies which allows your file carver of choice to recover them IMAGE There are of course many other scenarios and examples I could give but the long and the short of it is that if deleted data could be relevant to your case, you may need to investigate the shadow copies Which shadow copies should I look at further It has been suggested that, because each shadow copy is effectively a volume in it's own right which mirrors the size of the source volume, that if you have twenty shadow copies you will have to investigate twenty times as much data In Production Lineforensics this simply is not going to happen Therefore we need to make some educated guesses as to which shadow copies to look at Have our file carvers flagged any as meriting further investigation Do keyword searches point to any Were any shadow copies created just before or just after a particular event we are looking at Are there a rash of shadow copies created within a short time of each other by software installation or windows updates which we can exclude Once we have made our choices we can proceed further but it is not the case that the amount of data to be investigated is a multiplied by the number of shadow copies you chose toinvestigate This is because the majority of data within each shadow copy is exactly the same as the data on the live volume We are really only interested in the differences and I will discuss a method to do this later in this blog post What are we going to need For what follows we will need a Windows 7 box, Encase with the PDE module and some storage space formatted NTFS and ideally with File and Folder compression enabled We will also need George Garner's Forensic Acquisition Utility Method You will already have an Encase image of the drive you wish to investigate When this is loaded up into an Encase case you need to gather some information in respect to the shadow copies you wish to investigate further You will need to note the File Creation date and if you wish to be more precise establish the Shadow Copy ID stored at File Offset 144 for 16 bytes - bookmark as a GUID in Encase IMAGE IMAGE Next you will have to mount the volume containing the shadow copies as an emulated disk using the Encase PDE module On my box the mounted volume was allocated the drive letter II am using Windows 7 - every thing that follows should work in Vista and has worked for many people However for me, in testing using Vista it did not always work as expected -generating various permissions related errors -so far - touch wood- Windows 7 just worksRun a Command Prompt as Administrator and type the command substituting I for the drive letter allocated to your mounted volume vssadmin list shadows for I This will result in a list of all available shadow copies on the selected volume vssadmin 11 - Volume Shadow Copy Service administrative command-line tool C Copyright 2001-2005 Microsoft Corp Contents of shadow copy set ID 2202d8a9-1326-4254-9818-252ece858b17 Contained 1 shadow copies at creation time 10 12 2009 13 41 25 Shadow Copy ID ad2e71d0-48d6-44b9-9715-f5ff6b5a5643 Original Volume Volume 34e5a98a-1a1d-11df-a259-00236cb6de69 Shadow Copy Volume GLOBALROOT Device HarddiskVolumeShadowCopy4 Originating Machine Richard-MBP-Vis Service Machine Richard-MBP-Vis Provider 'Microsoft Software Shadow Copy provider 10' Type ClientAccessibleWriters Attributes Persistent, Client-accessible, No auto release, Differentia l, Auto recovered Contents of shadow copy set ID e13bb9d9-c522-422b-b92a-37f6d12363d9 Contained 1 shadow copies at creation time 15 12 2009 11 17 37 Shadow Copy ID d0e1c613-7892-47e1-9b7e-f638adac9d16 Original Volume Volume 34e5a98a-1a1d-11df-a259-00236cb6de69 Shadow Copy Volume GLOBALROOT Device HarddiskVolumeShadowCopy5 Originating Machine Richard-MBP-Vis Service Machine Richard-MBP-Vis Provider 'Microsoft Software Shadow Copy provider 10' Type ClientAccessibleWriters Attributes Persistent, Client-accessible, No auto release, Differentia l, Auto recovered Contents of shadow copy set ID 4db5347c-214a-4e5c-b785-0fd993f1dc33 Contained 1 shadow copies at creation time 15 12 2009 11 18 25 Shadow Copy ID b7621ae2-5efb-4929-aa35-39af3d6e39ac Original Volume Volume 34e5a98a-1a1d-11df-a259-00236cb6de69 Shadow Copy Volume GLOBALROOT Device HarddiskVolumeShadowCopy6 Originating Machine Richard-MBP-Vis Service Machine Richard-MBP-Vis Provider 'Microsoft Software Shadow Copy provider 10' Type ClientAccessibleWriters Attributes Persistent, Client-accessible, No auto release, Differentia l, Auto recovered Contents of shadow copy set ID 2445d9b6-58fd-4ac6-b73e-7bd0ebbec6cc Contained 1 shadow copies at creation time 15 12 2009 12 14 44 Shadow Copy ID 709f74d5-ded2-4294-a292-c7cc4db0e67b Original Volume Volume 34e5a98a-1a1d-11df-a259-00236cb6de69 Shadow Copy Volume GLOBALROOT Device HarddiskVolumeShadowCopy7 Originating Machine Richard-MBP-Vis Service Machine Richard-MBP-Vis Provider 'Microsoft Software Shadow Copy provider 10' Type ClientAccessibleWriters Attributes Persistent, Client-accessible, No auto release, Differentia l, Auto recovered Contents of shadow copy set ID c9e7850a-87db-4dbc-9d72-40749665d80d Contained 1 shadow copies at creation time 09 02 2010 07 26 39 Shadow Copy ID 2a871fe5-21f7-4fb6-b8e9-65e194a62901 Original Volume Volume 34e5a98a-1a1d-11df-a259-00236cb6de69 Shadow Copy Volume GLOBALROOT Device HarddiskVolumeShadowCopy8 Originating Machine Richard-MBP-Vis Service Machine Richard-MBP-Vis Provider 'Microsoft Software Shadow Copy provider 10' Type ClientAccessibleWriters Attributes Persistent, Client-accessible, No auto release, Differentia l, Auto recovered It can be seen that the Shadow Copy ID number I bookmarked as a GIUD is identified by VSSAdmin as HarddiskVolumeShadowCopy5 The next step is to image this shadow copy using the Forensic Acquisition Utility a version of dd that works in Windows At the command prompt navigate to the path of the utility and type the command C FAUx64dd if HarddiskVolumeShadowCopy5 of G shadow5img --localwrt It can be seen that the input file is referenced as HarddiskVolumeShadowCopy5 and the output file which I chose to name shadow5img is located on G This volume is an NTFS formatted volume with file and folder compression enabled --localwrt is a switch required to allow the utility to write to the G drive The response at the command prompt will be similar to The VistaFirewall Firewall is active with exceptions Copying HarddiskVolumeShadowCopy5 to G shadow5img Output G shadow5img 44048285696 57868808192 bytes compressed uncompressed 55187 1 records in 55187 1 records out 57868808192 bytes written Succeeded Enabling file and folder compression reduced the dd image from about 59GB to 44GB Whilst imaging make sure that you have carried out an hash analysis in Encase of your source volume and create a hash set from it Add only this hash set to your libraryOnce imaging completes add the image to Encase via the add raw image option and carry out a hash analysis Create a condition which filters out files that match a hash setThe following screen shot shows that there are 237024 files contained within the image of HarddiskVolumeShadowCopy5 broadly the same as the source volume IMAGE Apply the condition which filters out files that have the same hash value as those in the original image and it can be seen that the amount of new or different files is considerably reduced to 7864 files with the caveat that some of the original files may have been moved -which may or may not be relevant in your case IMAGE I think it can be seen therefore that it is possible to reduce the number of files you need to consider by filtering out the duplication between the original volume and the shadow copy A Note of Caution about the Shadow Copy Images When you image a Shadow Copy and add it into an Encase case as described above it is easy to think of the image as a point in time snapshot of the entire volume including the areas of the volume we refer to as unallocated clusters Unfortunately it does not appear to be However your forensic tool Encase in my case is likely to process it as if it was the entire volume In my test case used to illustrate this blog post I imaged at 14 47hrs on 9th February 2010 two shadow copies -one created at 15 12 2009 11 17 37 and one created at 09 02 2010 07 26 39 At 15 12 2009 11 35 I copied a folder entitled Sony from an external device to the desktop of my user account on this Vista box It can be seen in the screen shot below It is a live folder containing files and has not been deleted IMAGE It can also be seen within the shadow copy created on 9th February 2010 as expected IMAGE And as expected it cannot be seen in the earlier shadow copy created prior to the folder being copied IMAGE However unexpectedly when I ran the Encase Recover Folders feature across the HarddiskShadowcopy5 volume it found traces of the Sony folder and in fact many other files post dating the creation of the shadow copy IMAGE The Encase Recover Folders feature parses unallocated clusters looking for folder metadata It seems that it found data in unallocated clusters relating to the current volume Therefore it seems to me that any deleted but recoverable data needs to be treated with caution Other MethodsSo far in this post I have discussed imaging the shadow copy pseudo-device It is possible to mount the shadow copy as a symbolic link There are various methods discussed using VMs etc The most streamlined approach seems to me to be Mount shadow copy with Encase PDE create a symbolic link in this example at the root of C using the command mklink d c shadow_copy5 GLOBALROOT Device HarddiskVolumeShadowCopy5 drag the created symbolic link into a separate instance of Encase for me using the same instance as the one running PDE blue screened my box which causes Encase to treat the files and folders accessed via the symbolic link as Single files Create a logical evidence file of these Single files you may encounter some permissions issues along the way Methods involving accessing the shadow copies via Symbolic links will only provide access to the logical contents It may be that the object you are seeking is deleted but recoverable Referenceshttp blogssansorg computer-forensics 2008 10 10 shadow-forensics http wwwdigital-detectivecouk cgi-bin digitalboard YaBBpl num 1251461771http blogszynalskicom 2009 11 23 volume-shadow-copy-system-restore http windowsirblogspotcom 2009 11 working-with-volume-shadow-copieshtmlhttp blogstechnetcom filecab archive 2006 09 01 452845aspxhttp enwikipediaorg wiki Shadow_Copy http://www.secuobs.com/revue/news/193717.shtmlhttp://www.secuobs.com/revue/news/193717.shtml Secuobs.com : 2010-01-21 13:53:59 - Forensics from the sausage factory - Tableau have released their Tableau high performance software imaging product today To install it you first must have installed the latest Tableau firmware updater Once installed the interface is fairly simple to use I found some of the terminology in the GUI a bit odd For example the types of compression selectable for Encase e01 files are No Compression, Fast Compression or Good Compression whilst Encase provides the options none, good or best It seems that fast maps to good and good maps to best There also does not seem to be the ability to actually name the created e01 files- just their containing folders, again a little strange Now as far as performance is concerned in our environment it is slightly faster We image to a mapped network drive on a san across a gigabit ethernet network I imaged a Hitachi 80GB sata laptop hard disk via a Tableau T35i write blocker using FTK Imager 255 using the Encase e01 format - imaging completed in 51 minutes Using TIM to image the same drive took 44 minutes In both cases maximum compression was selected Obviously at this stage this testing is far from scientific but TIM seems to be between 10 to 15pourcents faster I will report how it goes on with larger 35 inch sata hard drives later http://www.secuobs.com/revue/news/183999.shtmlhttp://www.secuobs.com/revue/news/183999.shtml Secuobs.com : 2010-01-07 13:38:34 - Forensics from the sausage factory - I can just about remember the thrill of upgrading to a new OS When I was the new kid on the block I couldn't wait to upgrade from Windows 98SE to XP Pro somehow we missed out Windows ME Anyhow the newer kids on the block have migrated to Windows 7 it is prettier, more stable, blah blah Now I am a dinosaur with XP Pro 64 bit Anyway I had a call today about getting various aspects of C4P to play nicely with MySQL on a Vista 64 bit box In our office we don't actually use Vista on any of our forensic boxes so I thought I'd check out the issues on one of Windows 7 64 bit boxes As you know because if you are still reading this you probably use C4P along with a MySQL DB C4P interacts with the MySQL database in two areas 1 within Encase at Enscript level if the pre categorization option is selected 2 or via Data Migration Special Update Case Direct from C4P Hash Database within the Categorizer for Pictures program itself Both of these connections require an MySQL ODBC connector driver to communicate with the running MYSQL C4P hash database using a suitable database connection string Essentially in this scenario we have a choice of four MySQL ODBC drivers 1 MySQL ODBC 51 64 bit 2 MySQL ODBC 51 32bit 3 MySQL ODBC 351 64 bit 4 My SQL ODBC 351 32 bit All bar the 351 64 bit driver are installed via a Windows installer The 351 64 bit driver is slightly trickier to install - you need to unpack the zip, run a command prompt as administrator, navigate the command prompt to your unpacked zip folder and then run the command Install 0 Enscript level communication At Enscript level it is possible to modify the database connection string which allows you to specify which ODBC connector driver to use In testing on a Windows 7 64 bit box I have found that both the 351 and 51 64 bit drivers work if the drivers fail you generally get a long unintelligible error message The C4P 402 enscript allows the user to configure their own database connection string The string that works for me is IMAGE Provider MSDASQL DRIVER MySQL ODBC 351 Driver SERVER Your_server_name_or_IP_address DATABASE c4p_hash UID c4p_user PASSWORD password OPTION 3 Simply change 351 to 51 if you are using the later driver Categorizer for Pictures communication The database connection string used by this program is hard coded and not user configurable The program requires the 351 driver However I could not get the Data Migration Special Update Case Direct from C4P Hash Database option to work on the Windows 7 64 bit box using the 351 64 bit driver I suspect this is due to a permissions issue and tried to run C4P as administrator but I still failed to connect to the MySQL C4P hash db However I was able to get the Data Migration Special Update Case Direct from C4P Hash Database option to work using the MySQL ODBC 351 32 bit driver Conclusion Other combinations may work but on a Windows 7 64 bit box I recommend installing the MySQL ODBC 51 64 bit driver and the MySQL ODBC 351 32 bit driver to get C4P and the C4P graphics extractor enscript to play nicely with the MySQL C4P hash database http://www.secuobs.com/revue/news/179156.shtmlhttp://www.secuobs.com/revue/news/179156.shtml Secuobs.com : 2010-01-05 14:04:44 - Forensics from the sausage factory - As this is the first post of the year I would like to wish you a happy new year The posting title is the title of an excellent paper written by Harry Parsonage relating to Session Restore files created by the latest Mozilla Firefox and Internet Explorer 8 browsers These files may contain enough information to allow the browser to display a users workspace exactly as it was prior to a forced restart Obviously these files may contain significant evidence I am not going to steal Harry's thunder so download his paper from http computerforensicsparsonagecouk other otherhtm I know that Harry is not keen on blogs simply regurgitating information found elsewhere so I will try and add a little value Safari v4 Session Restore functionality is now a must have in modern browsers Another browser to have similar functionality is Safari v4 The last session information is contained in a file entitled LastSessionplist In Mac OSX 106 this file is stored at Users Library Safari In XP this file is stored at C Documents and Settings Application Data Apple Computer Safari I use the mac application - property list editor to review plists, there are windows applications to do this as well Firefox v356 running in Mac OSX 106 Harry's paper applies here in the main The sessionstorejs file is stored at Users Library Application Support Firefox Profiles XXXXXXXdefault http://www.secuobs.com/revue/news/178329.shtmlhttp://www.secuobs.com/revue/news/178329.shtml Secuobs.com : 2009-12-13 13:52:45 - Forensics from the sausage factory - I have seen a number of different Navman models now All of them have subtle variations on how to process them Although the underlying OS is Microsoft WinCENET 50 Core Version I did not have to access this device via Mobile Device Centre After applying some write blocking to my USB port this device was accessible as a mass storage device allowing me to image it with Encase I ended up with 114,759 sectors being imaged IMAGE The next step I took was to track down and consult a manual for the device in order to establish its capabilities I expect all devices to have saved Home, Favourites and Recent destinations and this device was no exception IMAGE In addition however this device can save trip logs, pre-planned itineraries, pictures and be paired with a mobile phone Almost all the relevant data is stored within xml formatted files Microsoft Excel 2007 is an excellent tool for examining these files and subsequently reporting on them I use the Get External Data From Other Sources From XML Data Import option via the data tab and allow Excel to sort out the formatting IMAGE A good place to start is the file pathsxml stored at the root of the partition This file details the location of some of the relevant files This is a more definitive list MyFavouriteLocationsxml - used to store the home location and favourites MyRecentLocationsxml - used to store Recents and also Journey Starts MyMultiStopLocationsxml - used to store saved multi stop journeys MyRoutexml - used to store the current journey which is in effect the last journey -on the device I examined this file was deleted but recoverable UserSettingsxml used to store device settings including where the unit was turned off When a user enters a new address the menu shows previously entered towns or cities, road names and postcodes This data is stored in the following files DWRecentPocodexml Previously entered postcodes, most recent first DWRecentRoadxml Previously entered road names, most recent first DWRecentPlacexml Previously entered towns or cities, most recent first There are a number of presumably back up files also containing the same as far as I could see xml formatted data MyFavouriteLocations_bakxml MyRecentLocations_bakxml MyMultiStopLocations_bakxml There are also two files that appear to be temporary files which were deleted but recoverable, containing xml formatted data MyRecentLocations_Newxml MyMultiStopLocations_Newxml All of the above mentioned xml files are parsed very tidily using Microsoft Excel 2007 I use the same program to create an html version of the worksheet after a little tidying up The longitude and latitude values need to be divided by 100,000 I populate a new column using the formula HYPERLINK http mapsgooglecouk maps q K3 100000 L3 100000 , Click here to view in Google Maps The cell K3 contains the Latitude and L3 the Longitude The formula creates a clickable hyperlink to the Lat Long in google maps There are one or two other files of interest destdatadat - which contains the address used for the last navigated journey gpslogini - detailing the location of trip log data default_settingsxml -which in the FAVOURITES RECENTS MULTI-STOP section appears to detail the maximum number of favourites and recents pcd - on the unit I examined I could not locate a pcd file however I understand from Andy Sayers that this file if it exists contains the phonebook from a paired mobile phone Log001log - again I did not see this file but if it exists it contains GPS track logs Because we have physical access there is also a possibility of recovering relevant data from unallocated clusters I located records in unallocated using the keyword References Sat Nav Examination Guidance Notes Andy Sayers Navman S-Series S30, S50, S70 S90i User Manual http://www.secuobs.com/revue/news/171446.shtmlhttp://www.secuobs.com/revue/news/171446.shtml Secuobs.com : 2009-12-08 00:43:27 - Forensics from the sausage factory - This device can be purchased very cheaply now from places like Asda and ebuyer It runs Astrob Turbodog4 satellite navigation software within a Microsoft WinCENET 50 Core Version OS Although I have not examined one I believe a number of Navigo devices run similar software It has an SD card slot which was unpopulated in the one I looked at The internal memory can be accessed like many similar devices via Mobile Device Centre in Vista which makes available a volume entitled ResidentFlash I disable writing to USB devices by modifying the registry there are many utilities about to do this Simply paste the text below into a text file, give it a reg file extension and then execute it and then reboot HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Control StorageDevicePolicies WriteProtect dword 00000001 After copying and creating a logical evidence file of ResidentFlash I found three notable files within the MobileNavigator folder RecentDestdat FAVDAT SystemSetdat RecentDestdat stores up to fifty of the recently navigated to locations These locations are stored in records of 104 bytes in length The first record starts at the first byte of RecentDestdat, so by viewing the file in Encase with the view pane set to hex and dragging the view to show 104 bytes per line assuming you have twin monitors , it is possible to see all the relevant data Each location record stores Longitude and Latitude as 8 byte doubles which unfortunately Encase does not natively decode The data interpreter in Winhex can do this The hex editor 0xED on a mac can also do this but rounds up to fewer decimal places than Winhex So given a fully populated RecentDestdat file you have one hundred doubles to decode I turned to my friend Oliver Smith over at Cy4or who wrote me an enscript which parses out the records to a csv file Email me with a brief note about who you are for a copy IMAGE Recent Destinations also log the time entered, so very unusually some meaningful time and date information may be extracted Providing these times have been recorded whilst the device can see satellites they are accurate and stored at the configured time zone If a destination is entered when the unit can not see the sky and if the battery had been previously discharged it appears that the recorded time and date would be soon after 00 00 hours 1st January 2007 IMAGE I have decoded each 104 byte record as shown in figure 1 IMAGE Figure 1 click on image for larger version FAVDAT contains user configured Favourites stored in 536 byte records Once again the Longitude Latitude are stored as eight byte doubles in the first sixteen bytes of each record SystemSetdat appears to store the users Home location and again the Longitude Latitude are stored as eight byte doubles Within the MobileNavigator folder there is a folder entitled Trace This was empty in the one I looked out however the manual states The unit is capable of logging all positioning information received from the GPS satellites during navigation It then uses this information to draw a track of the route on the map This enables you to review the route information at a later time I imagine that should this feature be enabled a file of some sort will be stored in this folder IMAGE References http binatonegpscom gps download manual X350IIpourcents20Userpourcents20Guidepourcents20 Turbopourcents20Dog pourcents20-pourcents2020080910pdf http enwikipediaorg wiki Double_precision_floating-point_format http://www.secuobs.com/revue/news/169454.shtmlhttp://www.secuobs.com/revue/news/169454.shtml Secuobs.com : 2009-11-13 14:49:48 - Forensics from the sausage factory - A recent case resulted from an entry in a compromised web server log The GET request included the string Mozilla 40 PSP PlaySation Portable 200 Our suspect had used a PSP to do dodgy stuff and the PSP eventually came my way I looked around for some information but did not find a large amount of information, essentially the most useful items were an Encase Message Board post and Chapter 9 of a book entitled Advances in Digital Forensics V which I read via Google Books Sony PlayStation Portable hand held consoles have an inbuilt wi-fi adaptor and can therefore connect to the internet The device utilises the Netfront browser There are a number of different versions and firmware versions The one I looked at had a label indicating that it was a PSP1001 This site details the many different types available A PSP1001 is known as a PSP Fat as opposed to a PSP Slim The one I looked had version 405 firmware These type of PSPs have a small amount of internal NAND flash memory and a Memory Stick ProDuo flash media card As far as I can ascertain it is not possible to examine the internal NAND memory of devices beyond 15 firmware because you would require hacked firmware and modified hardware to do it The browser does store its cache in this area but I believe as a default only 512KB is used for this purpose Some information can be derived from the internal memory via a manual exam Essentially then, we are left with the Memory Stick ProDuo flash media card Our Tableau USB write blocker would not recognise the card I had however I was able to image it using our Helix imaging box and Guymager The card had a FAT16 file system and was examinable with Encase Files of interest On the card I looked at only two files were of interest both in the folder PSP SYSTEM BROWSER bookmarkshtml contained what you would expect -user created bookmarks historyvdat contained internet history Scott Conrad, Carlos Rodriguez, Chris Marberry and Philip Craiger's paper within Advances in Digital Forensics V refer to two further files of interest historyidat and historysdat I got my hands on a test PSP1001 with the same firmware as my suspects 405 and in testing I was not able to populate these files with any data The files existed but I was not able to cause details of either Google Searches or user typed URLs to be stored in these files My suspects card had an unpopulated historyidat file and no historysdat file As noted by Conrad et al I found in testing that I could only cause writes to historyvdat by shutting the browser down gracefully Simply turning off the PSP without shutting down the browser did not commit that sessions history to historyvdat Structure of historyvdat The structure of historyvdat is discussed by Conrad et al however they suggest that elements of the file were best decoded by introducing the data into a test PSP for decoding For example the date of each history entry could be ascertained this way I would prefer to carry out a completely static examination if possible, not least because on my suspects card I had recovered a number history records in slack space and a manual examination can be a little laborious I have therefore decoded the records a little bit further as shown below at Figure 2 and Figure 3 Each historyvdat file is headed with 66 bytes of data starting with the string Ver01 Within this 66 bytes are two further bits of plain text - NFPKDDAT and BrowserVisit Immediately following BrowserVisit is the first history record The most recent record is listed first, the oldest last Each record can be located using a GREP expression to search for the header - in Encase x03 x00 x01 x00 -see Figure 1 below Records can be found in slack space and unallocated clusters IMAGE Click on image for larger version Figure 1 IMAGE IMAGE Figure 2 IMAGE Figure 3 A significant addition to the research of Conrad et al is the decoding of the date for each record The date is recorded in the two bytes following the URL and is stored Little Endian In Encase sweep these two bytes and right click, select Go To and check Little-endian The value is the number of days since the Unix epoch 1st January 1970 This web site provides a good date calculator IMPORTANT NOTE re dates the dates stored are in accordance with the PSPs internal clock The clock resets when the battery is exhausted With the firmware I looked at the reset date was 1st January 2008 This date is 13879 days from the Unix epoch I speculate that the average user is unlikely to reset the date each time the battery exhausts, therefore I would expect to see a lot of dates in January 2008 References and thanks http wwwedepotcom reviews_sony_psphtml http enwikipediaorg wiki PlayStation_Portable Web_browser Forensic Analysis of the Sony Playstation Portable - Scott Conrad, Carlos Rodriguez, Chris Marberry and Philip Craiger https supportguidancesoftwarecom forum showthreadphp t 33057 highlight psp http wwwcomputerforensicsworldcom modulesphp name Forums file viewtopic t 654 highlight psp Thanks to Pete Lewis-Jones and Simon Maher for their help brain storming the date problem IMAGE http://www.secuobs.com/revue/news/160568.shtmlhttp://www.secuobs.com/revue/news/160568.shtml Secuobs.com : 2009-11-02 17:25:40 - Forensics from the sausage factory - I blogged earlier this year about the Garmin Nüvi 200 Sat Nav device and I have now had a crack at a Garmin Streetpilot C510 The Streetpilot like the Nüvi 200 stores waypoints in a file Currentgpx found within the Garmin folder This folder is accessible when the device is connected to a computer due to the fact that the device is designed to act as a mass storage device It is probably worth expanding on what a waypoint is Garmin's FAQs define them as Waypoints may be defined and stored in the unit manually, by taking coordinates for the waypoint from a map or other reference This can be done before ever leaving home Or more usually, waypoints may be entered directly by taking a reading with the unit at the location itself, giving it a name, and then saving the point Essentially as far as both the Garmin devices discussed here are concerned the waypoints recovered from Currentgpx are the users favourites and home location Apologies for teaching granny to suck eggs but it is probably worth stating that waypoints are not Track Logs Most Streetpilots and Nüvi 200s do not store any tracking information there is an unsupported hack which allows the modification of some units firmware to store tracking information As commented in my previous posting and within the SatNav forensics forum over at Digital Detective these Garmin devices do store other data not contained in Currentgpx This data is the Recently Found locations which are effectively the last fifty locations a user chose to navigate to or at least look at on the device Evidentially this data may be useful Up to now a manual exam using something like Fernico ZRT has been the answer I have tried out a slightly different methodology Suggested Methodology for the examination of Garmin Streetpilot C510 May work with other models Download Garmin USB drivers Download Garmin xImage version 23 Download G7toWin Install Ximage on your workstation Turn on Garmin sat nav and press and hold your finger over the onscreen battery symbol for about 10 seconds This should take you into a hidden diagnostics menu IMAGE On your Forensic Examination workstation run the Garmin USB drivers executable and work through to this screen IMAGE Connect Garmin sat nav to your Forensic Workstation and complete the USB driver installation the sat nav must be displaying the hidden service mode - if it isn't it will act as a mass storage device IMAGE Run G7toWin on your workstation it does not need to be installed and adjust the configuration to allow communication via USB IMAGE Within G7toWin via the menu bar select GPS Download from GPS All All available waypoints will display Via File Save As you can save the data to your filetype of choice eg gpx, kml, xml It is possible that one of the fields may contain an illegal character - in my testing the comment field did I dealt with this in my exported kml and xml files with a decent text editor PSPad and the find and replace feature Applications that support xml and Google Earth are not usually tolerant of any illegal characters formatting Downloading of the waypoints is now taken care of Next I want to deal with the Recently Found locations I am going to suggest two approaches, which although relatively simple I have not seen documented elsewhere The version of the device you are using may dictate which approach you try Approach 1 You should still be at the Diagnostics Menu - press the Exit icon Via the main navigation menu select Where to Recently Found You should now see the first five Recently Found locations On your Forensics Workstation launch xImage, your device should appear in the Device field then click Next Select Get Images from the GPS then click Next Set Image Type to Screen Shot Clicking Next will allow you to save a screen shot of the currently displayed screen on the device Using this method you can quickly screenshot all the screens you would have photographed in a manual exam, after each screenshot click back to prepare for the next one IMAGE Approach 2 is more invasive, however I think principal 2 of ACPO guidelines applies Approach 2 You don't initially have to have your device connected to your workstation for this to work On the device select Settings Display In the Display menu enable Screen Shot This will cause a small camera icon to appear in the top right of the display Pressing this icon will cause a screen shot to be saved into the Garmin scrn folder upon the device Screen shot all the screens you would have photographed in a manual exam Connect device to workstation as mass storage device and cut and paste screenshots from it IMAGE IMAGE IMAGE http://www.secuobs.com/revue/news/156242.shtmlhttp://www.secuobs.com/revue/news/156242.shtml Secuobs.com : 2009-10-26 17:43:30 - Forensics from the sausage factory - TIM is an acronym for Tableau Imager which unsurprisingly is new imaging software developed by Tableau Tableau promise astounding imaging speeds Apparently it will be available in beta form anytime soon Given the quality of the Tableau write blockers I think this software is definitely worth watching out for The latest info can be found here IMAGE http://www.secuobs.com/revue/news/154092.shtmlhttp://www.secuobs.com/revue/news/154092.shtml Secuobs.com : 2009-10-12 09:44:54 - Forensics from the sausage factory - Back in July 2009 I blogged about the potential of video triage I was commenting on its effectiveness and had used a program written by John Douglas to explore what was possible Mark Woan added a very interesting comment to that post, introducing a program he had written - Forensic Video Triage I have now tried out a series on enscripts written by Oliver Höpli which aim to provide the same functionality as both John and Mark's programs Essentially all three approaches utilise a third party video playing and manipulation program to create and store thumbnails of frames at set intervals throughout a video clip The investigator can then triage the video clip by reviewing the thumbnails as opposed to playing the video The gallery feature in Encase for example makes reviewing the thumbnails a considerably quicker experience than playing the videos John's program utilises VLC, Mark's uses ffmpeg and Oliver's enscript calls upon mplayer for thumbnail creation Each of these video utilities have inbuilt codecs and their capabilities may vary - in other words a video clip may play with one and not the others Oliver Höpli has integrated the process much more closely with Encase with his suite of enscripts, and for me this can only be a good thing If you are an Encase shop the pre-processing is considerably reduced and the whole process is more seamless leading to greater productivity The main enscript runs across selected as in blue checked movie files within your case and parses out thumbnails into a logical evidence file Another enscript creates a folder structure within the Encase bookmarks tab based on the contents of the logical evidence file Each video clip has a folder within bookmarks making it an easy process to review the thumbnails To get it all working the main enscript needs a little configuration which I found a little fiddly Ahead of time you need to install a version of mplayer suitable for Windows, I found a version at http smplayersourceforgenet downloadsphp tr_lang en and downloaded the Windows package with installer Oliver directs you to the standard mplayer site which I found a bit difficult to navigate Once mplayer is installed you need to configure the main enscript by editing it to include the location of mplayerexe and the location of a suitably large temp directory On my box the lines of the enscript are note the double Configuration Path to MPClassicexe mpclassic C Program Files x86 MPlayer for Windows mplayer Tempfolder which will be used to extract the movies and create the thumbnails expDir C Temp time interlace between to frames films under 1 minute OneU 5 films between 1 and 5 minutes FiveU 10 films between 5 and 30 minutes BetweenFiveAndThirty 20 films over 30 minutes ThirtyU 30 Oliver's enscript can be found in the Guidance Software Download Center and comes with a Readme which needs reading IMAGE http://www.secuobs.com/revue/news/149546.shtmlhttp://www.secuobs.com/revue/news/149546.shtml Secuobs.com : 2009-09-20 17:54:28 - Forensics from the sausage factory - Windows Photo Gallery is built in to all Vista editions and allows the management of photographs and other pictures together with the ability to carry out a number of basic photo editing tasks Two forensic artefacts of this program are discussed in this post Original Images Folder The program allows users to revert to the original picture with one click should they not like the results of their editing This feature provides investigators with a very useful artefact When a picture has been edited the original unmodified version is stored at pourcentsLOCALAPPDATApourcents Microsoft Windows Photo Gallery Original Images The file name of this original unmodified version is renamed - the relevant Microsoft Knowledge Base Article details the file name construction When the original unmodified version of the image is saved, the image file is renamed by using a combination of a unique ID and the original file name The unique ID is determined by theSystemImageImageID file property If there is no SystemImageImageID file property value, a GUID is created The following is the new file name construction ' ' unique ID ' ' '-' file name The following is an example of a renamed original file 198EB054-44E6-441e-87C8-9B29C5198DE6 -image1jpg To example this I have edited and renamed the Windows sample picture Toro-toucanjpg quite apt considering the forthcoming Arthur's day using Windows Photo Gallery IMAGE The Original Images folder is created the first time a picture is edited with the application and is a hidden folder From a forensic point of view we might need to identify the edited picture which may have been renamed We can locate the edited picture by searching for the unique ID referred to above Essentially take the original file name 1F7BA35C-33F2-499E-92A1-0FBE9477C8CA -Toco Toucan in my example and strip it down to 1F7BA35C33F2499E92A10FBE9477C8CA This value is embedded within metadata stored within the edited file known as an XMP Message block and also in one further location Using FTK Imager we can see this value stored in the two locations within the edited file click on screenshots to see a larger version IMAGE IMAGE In the second screenshot part of the XMP message block can be seen The editing application is also detailed Pictures PD4 Windows Photo Gallery stores metadata about the pictures indexed by it in a database file PicturesPD4 at the location C Users YourUser AppData Local Microsoft Windows Photo Gallery Tim Coakley's Simple Carver Suite contains a program Windows Photo Gallery Viewer to parse this file I have found that substituting a test PicturesPD4 file in a Vista VM lets say with your suspects PicturesPD4 file can produce some meaningful results I found that the best results can be achieved when the test Windows Photo Gallery is set to display tiles view Although a blog discussing the transfer of PicturesPD4 files from machine to machine suggests that the test machines Volume Serial Number needs to match that of the suspects This can be done with the Windows Sysinternals utility Volume ID v20 References http supportmicrosoftcom defaultaspx kb 944370 http blogsmsdncom pix archive 2006 08 16 702780aspx http wwwadobecom devnet xmp pdfs XMPSpecificationPart3pdf http aaron-kelleynet blog 2008 03 migrating-vistas-windows-photo-gallery-database IMAGE http://www.secuobs.com/revue/news/142655.shtmlhttp://www.secuobs.com/revue/news/142655.shtml Secuobs.com : 2009-08-18 00:35:59 - Forensics from the sausage factory - Volume shadow copies in Vista are often the elephant sat in the corner in many cases We know they exist and we know they can contain lots of data, but we often choose to ignore them A recent case required some keyword searches and an examination of picture files A the completion of the keyword search most of the hits were within files with names similar to bab9c293-d150-12dc-a44f-021d253da909 3708876a-d176-4f38-b7bb-05036c6bb821 The view pane within Encase 614 displayed the contents in a nice light blue colour which I now know is a new feature in 614 to indicate the contents of uninitialised files The files were all located within the System Volume Information folder on the root of the volume and are the Vista Volume Shadow Copies By default 15pourcents of the capacity of the volume is allocated by Vista to store these copies The C4P graphics extractor enscript carved most of the notable pictures out shadow copies also At this stage I have known examiners report their findings alluding to the fact that that the notable artefacts are within the file bab9c293-d150-12dc-a44f-021d253da909 3708876a-d176-4f38-b7bb-05036c6bb821 In most cases I think you need to drill down further In order to do this I mounted my Vista image with Encase PDE and used Liveview 07b to create a working VM using VMWare Workstation 6 Having logged into my suspects account I ran a command prompt as administrator and entered the command vssadmin list shadows for c This provided a nice list of available shadow copies Having selected one I entered the command mklink d c shadow_copy7 GLOBALROOT Device HarddiskVolumeShadowCopy7 This created a symbolic link in the root of C which in Windows Explorer at any rate appears exactly like a shortcut to a folder Clicking on it produced the error message shown below IMAGE I believe this error is probably generated by a permissions issue, however I was not able to overcome it and Rob Lee over at Sans Computer Forensics suggests this methodology does not work I think Jimmy Wegg however has had some success with a program written by Dan Mares - VSSexe I therefore turned to ShadowExplorer version 043820 This program allows the user to view the contents of Volume Shadow Copies that exist on any volumes within the installed system The contents are displayed in an Explorer like view allowing the user to export out any file or folder to an export directory I exported the User profile I was interested in to an export directory Unfortunately it seems that only the Last Written date is preserved in this process and all other time stamps are tripped I then tried to copy this export directory out of the VM to my workstation and encountered errors probably due to files within the profile with illegal windows file names To overcome this I zipped up the export directory and copied the zip out of the VM Once unpacked I then added the exported folders into Encase as single files and created logical evidence files from them Having done this I was able to resolve most of my keyword search hits and pictures to actual files as opposed to being simply within a volume shadow copy References http blogsmsdncom adioltean archive 2008 02 28 a-simple-way-to-access-shadow-copies-in-vistaaspx IMAGE http://www.secuobs.com/revue/news/131676.shtmlhttp://www.secuobs.com/revue/news/131676.shtml Secuobs.com : 2009-08-02 23:08:54 - Forensics from the sausage factory - Probably not an entirely accurate title but I came across two enscripts the other day both of which are aimed at quickly triaging the results of a comprehensive Internet History search Users of this functionality within Encase version 6 will know that often you can be faced with reviewing hundreds of thousands of entries on the records tab Many times all you need is evidence of user inputted search terms There are conditions available to start sorting the wheat from the chaff however it is difficult for these conditions to be totally focussed due to the variation in url formation This is where both enscripts come in as they are both designed to parse the actual search term used from a variety of search engine urls Searchterms V 11 parses out the search term used and where possible the time and date it was carried out into note bookmarks The enscript has been written to support a claimed 145 separate search engines Internet Search Term Finder parses out unique search terms to Log Record bookmarks and stores the term along with its associated url The script is in fact an Enpack so it is difficult to determine exactly how it works, however it seems to base its search on elements from the query url A neat feature is that it is configurable, allowing the addition of a new prefix to the query string to cater for a different or new search engine Within an XP Pro SP3 VM I carried out a series of searches utilising the Firefox v3011, Internet Explorer v8, Opera v964 and Safari v402 browsers I ran the Search for internet history Comprehensive search option within Encase 614 and established that all my searches had been parsed into the records tab, with the exception of those carried out with Safari v402 It turns out that Encase 614 does not support parsing internet history from this version of Safari I then ran both Enscripts and can report that both parsed out my test search terms from the records tab The results can be viewed within bookmarks For me the output of the Internet Search Term Finder is preferable and it usefully creates a Log Records bookmark which allows the easy export of results into a spreadsheet Both successfully hit the spot in respect to users quickly reviewing search terms within internet history IMAGE http://www.secuobs.com/revue/news/127337.shtmlhttp://www.secuobs.com/revue/news/127337.shtml Secuobs.com : 2009-07-22 10:03:25 - Forensics from the sausage factory - A recent case involved the download of a contraband file and I was asked to establish what happened just before the download in order to try and establish who was responsible This scenario is fairly commonplace and I usually start with a timeline analysis of the file system activity around the event in question An invaluable enscript for this is Geoff Black's Timeline Report which can also be found within the Guidance Software Enscript Resource center The html report produced by this script is particularly cool In my case my analysis showed there were a number of link files in a number of system restore points all created at a time and date just before the download They were all named in the form A000XXXXlnk xxxx being a variable number and I could see from a rough and ready examination of the data that they all pointed to one particular file saved on the users desktop As these link files were stored within restore points the first hurdle to overcome was to establish the link files original name and path This information is stored within the changelog files of each respective restore point Manually searching through this file for the restore point file name eg A000XXXXlnk will reveal the files original path There used to be an enscript for parsing the changelog files but it was written for version 5, however I was able to track down a version that worked in version 6 at Paul Bobby's excellent blog web site this enscript can also be found within the Guidance Software Enscript Resource Center The changelog files contain a lot of information and all I really needed was the original filename and path - the scripts output may be a little bit of an overkill Another utility out there is the Mandiant Restore Point Analyzer I used this utility to determine the original paths and file names All of the link files related to one link file stored within a users Recent folder In my case the file the link file linked to was created and stored upon the desktop, thus causing the initial link file to be created Over a period the target file was opened and additional information written into it, thus causing the link file to be updated Harry Parsonage's paper on link files illuminates this further I copied the link files out of my image and loaded them into Sanderson Forensics Linkalyzer This program decodes and displays the contents of link files into a grid much like a spreadsheet I was going to post a screenshot but sanitising the contents became too much of a pain and very quickly allowed me to see that the target file was being regularly accessed and modified Because the target file size is also stored within the link file I could also see that the file size was growing over time The program produces good reports and has many other abilities beyond the scope of this blog post, but in short I thoroughly recommend it Now as far as my case was concerned the target file was clearly linked to the suspect and it proved worthwhile delving into those restore point link files References http computerforensicsparsonagecouk downloads TheMeaningofLIFEpdf Forensic Analysis of System Restore Points in Microsoft Windows XP Now what would be really useful is an enscript that simply parsed out the original path and filename of only all user selected blue checked files sitting in restore points I would envisage the output to be a three column csv file - Current Filename, Original Path and Filename, Restore Point Creation Date IMAGE http://www.secuobs.com/revue/news/123423.shtmlhttp://www.secuobs.com/revue/news/123423.shtml Secuobs.com : 2009-07-10 17:30:51 - Forensics from the sausage factory - Paul Sanderson's VidReport has been referred to here and there latelyC4M also is regularly brought up in conversations I have with peoplesuch an interesting life I lead Triage is certainly the flavour ofthe month right now So I thought it worth writing a few lines aboutmy recent experiences of triaging videosI have often voiced the opinion that reviewing a couple of hundredvideo files in a case is not that bigger a deal and on that basis Ihave not been too keen on using C4M Anyhow I've just had a case withabout 170 video clips to review and thought it would be a good case totry out the video triage approach My normal approach is to use VLC asa file viewer in Encase to preview each video This took about an hourand a half some of the videos were quite good ;- I then used John Douglas's video triage program which I think hesupplies free to LE to review the same video clips To use thisprogram you copy out the clips you wish to review and point theprogram at the folder containing them It processes each clip bytaking a screen capture at a configurable interval and putting eachscreen capture into a subfolder named after the videos file name Oncethe program has processed all the clips you will have a sub folder foreach one, containing the screen captures I then simply dragged thefolders into Encase as single files and previewed the contents of eachfolder in gallery view I previewed all the clips in fifteen minutesMy scepticism of video triage was clearly unfoundedIMAGEhttp://www.secuobs.com/revue/news/118854.shtmlhttp://www.secuobs.com/revue/news/118854.shtml Secuobs.com : 2009-06-18 15:14:04 - Forensics from the sausage factory - The new Microsoft search engine Bing has been in the news latelyOne of the facilities it provides is a video search which in itself isold hat, however the results page features in-line video previews Auser can turn safe search off and perform a search which results in ascreen of thumbnails of the located videos Hovering the mouse over athumbnail results in a short preview of the video being played withinthe thumbnailThe thumbnail videos are cached as FLV flash video files however theinteresting feature is that the URL host of the flv files in my earlytests was ts3imageslivecom The ts3 part was variable Microsoftare processing the video using Smart Motion Preview technologyproducing effectively a trailer of the most relevant parts Microsofton or about 12th June 2009 began to serve all explicit video smartmotion previews from ts4explicitbingnet The ts4 part is variableThese in-line video previews allow the viewing of contraband materialwithout leaving a significant footprint At least for Bing the searchquery is saved within the browsers internet history and the smartmotion preview is cached as a FLV file with the word explicithelpfully added into the cached items urlThe video search at askcom also provides in-line video previewshowever these previews seem to be streamed - another kettle of fishaltogetherIMAGEhttp://www.secuobs.com/revue/news/111184.shtmlhttp://www.secuobs.com/revue/news/111184.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - From time to time I hear colleagues discussing the merits of an artefactreported by Encase as being in pagefilesys It may be a picture oreven an e-mail attachment as referred to in this Forensic Focus postI have seen reports detailing these artefacts along with explanationsof what virtual memory isI have always thought that pagefilesys was pre-allocated an area ofthe hard disk and did not necessarily have to write to it all As thiswas raised again recently I decided to carry out some testsI configured a XP VM not to use a Paging Fileand then ran Eraser v5861 with a Task to wipe Unused Space withwhich in ASCII is UN As expected I ended up with most of UnallocatedCluster being overwritten with UNUNUN etc x55 x4EI then turned the pagefile back on and rebootedI found that a considerable proportion of my quite largepagefilesys was UNUN etc sampled in this sweeping bookmark-Full Path PagefiletestCpagefilesysFile Created 05/06/08 09:41:25Last Written 05/06/08 09:43:35Physical Size 1,794,691,072Logical Size 1,794,691,072Initialized Size 1,794,691,072Starting Extent 0C-C3307487File Offset 32763080Length 3104UNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNUNand shown in this screen printThe moral of the story is that the pagefilesys is not always what itseems - perhaps more specifically what is reported as being within itmay have resided within unallocated clusters prior to pagefilesysbeing created or resizedReferenceshttp://wwwaumhaorg/win5/a/xpvmphphttp://wwwpetricoil/pagefile_optimizationhtmIMAGEhttp://www.secuobs.com/revue/news/103564.shtmlhttp://www.secuobs.com/revue/news/103564.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - I blogged here about a case where the suspect had repeatedly re-installedhis OS The suspect is accused of creating a CD at a particular timeprior to the installation of the current OS Putting aspects relatingdirectly to the CD link files, volume serial number etc aside weneeded to find evidence that the computer was or was not being used atthe material timeAfter reading Harlan Carvey's blog I liked the idea of recoveringevent logs from unallocated After hunting around Harlan's and a fewother blogs together with Steve Bunting's site I found and had a readof Rich Murphey's paper Automated Windows event log forensicsFollowing his advice we created a GREPx30x00x00x00x4cx66x4cx65x01x00x00x00x01x00x00x00and utilising the custom file finder in Encase carved out 512kb filesfrom unallocated The issue of corrupt event logs was considered asdiscussed on Steve Bunting's site and Rich Murphey's fixevt tool wasrun across all the carved evt files in the export folder to deal withthis issueI had to decide which tool I could use to parse out the contents ofthese evt files I would have liked to use one of Harlan's perlscripts or utilities but despite seeing references to them everywhereI could not lay my hands on them guess I'll have to buy the book Idid try out Event Log Explorer and this program was very successful inparsing out many of the carved out evt files and displaying them in afunctional GUI I was impressed with the programs filtering tools andit's ability to save a project into a workspace When I first wrotethis up I missed the obvious - you can also drag the carved out evtfiles back into Encase as single files and use the Windows Event LogParser module part of the Case Processor Enscript to parse them Itseems to create a separate worksheet for each evtIMAGEhttp://www.secuobs.com/revue/news/103563.shtmlhttp://www.secuobs.com/revue/news/103563.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - I blogged a short time ago about the Navman iCN 310 satellite navigationdeviceA iCN 510 versionID 3001008 BuildTime 2004-11-22, 12:38:48 has nowbeen submitted and it is a bit more complicated to deal with It stillhad a 128mb MMC card but it only had maps on The dat files I neededto find were stored within internal memory The problem to overcomewas how to access it This navman is running a Windows CE NET 42 OSand in Windows XP Microsoft Active Sync is required to access it Theplan was to use Paraben's Device Seizure software to image the deviceThe plan went pear shaped when Active Sync wouldn't connect to theNavman - I am not sure why but I suspect a driver was missingsomewhere In desperation I connected the device to a Vista box andsuprisingly detected the Navman immediately as a mobile device andallowed me to copy off the aformentioned dat files In Vista ActiveSync has been replaced with a free download - Windows Mobile DeviceCenter I instaled this software and it then identified the Navman asa Windows CE device Within the device there appeared to be twovolumes: and My Flash DiskWithin My Flash Disk there are four notable files:* Recentdat* FavVer3dat* routedat* tripPlandatRECENTDAT stores up to thirty of the recently navigated todestinations These destinations are stored in records of 520 bytes inlength Each destination has its Lat/Long coordinates stored in 8bytes starting at Record Offset 507 These are decoded by bookmarkingin Encase as a 32 bit integer In the UK Latitude will begin in therange 49-59 and is decimally notated Longitude is in the range -5 to+16 ish When bookmarking as a 32 bit integer Longitude is shownfirst and will often be a negative value ie anywhere west ofGreenwichFAVVER3DAT possibly stores up to 200 user entered favouritedestinations These favourite destinations are stored in records of1508 bytes in length Each destination has its Lat/Long coordinatesstored in 8 bytes starting at Record Offset 352 These are alsodecoded by bookmarking in Encase as a 32 bit integerROUTEDAT I speculate is used to store the origin of the lastnavigated journey Coordinates can be found at record offset 507TRIPPLANDAT contains destinations set by a user when planning a tripwith multiple destinations via Trip Planner in the main menu or viapop up menus in the Map Screen These destinations are stored inrecords of 532 bytes in length Each destination has its Lat/Longcoordinates stored in 8 bytes starting at Record Offset 504 These arealso decoded by bookmarking in Encase as a 32 bit integerWhere I can I try and download manuals for these devices because ithelps in mapping the features to the files containing user generateddata I found that the manual for the iCN 510 did not reflect the menuscreen I found The manual for the iCN 600 however did mirror what Isaw on this device I guess the software was upgradedGREP search expression for Encase to find coordinatesx4f-x55x00Another issue I am encountering with sat navs is flat batteries and nochargers Not all of them can be charged via USB however I have foundthat mobile phone chargers are a good stand in Motorola have acharger that happily charged this NavmanIMAGEhttp://www.secuobs.com/revue/news/103562.shtmlhttp://www.secuobs.com/revue/news/103562.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - Windows FE is a forensic edition of Windows PE boot CD It is forensicbecause it is not supposed to mount anything automatically This postwill not detail how to create a Windows FE disc because this can befound at the MS LE Portal and also here however I want to discusssome elements of why one would use it and also help to get over one ortwo gremlinsI have been asked Is it another Helix disc The answer is - it issimilar but it offers some advantages in certain situations The mainadvantage is being able to inject drivers into the ISO prior toburning This allows you to add drivers for the latest SAS raidcontroller or Dell SATA drive controller for example which is notalways possible in Linux working on the principle that there aregenerally more Windows drivers than Linux onesYou can also add your own forensic tools I have been able tosuccessfully add a full working copy of Encase 611 including Dongledrivers Strangely I have not been able to get FTK Imager to worksubsequently I have - see newer post I imaged a 149GB hard disk inan Apple MacBook Pro to a 500gb external usb hdd in 2 hours 6 minutesGremlin 1If you have seen the paper dealing with the discs creation and use youwill see that it states you should use the Diskpart utility to add andmount hard disks You will probably need to mount a disk as yourharvest or collection drive ie the disk you will save your imageto This aspect of the disks use proved to be slightly tricky Inorder to save an image to an external drive I had to put it online,assign a drive letter and remove it's read only attribute A number ofDiskpart commands are required to achieve this as discussed belowWindows FE boots up to a shell You will have a command prompt on theX drive which is a RAM disk To launch the Diskpart utility type:X:windowssystem32DiskpartTo establish which disks can be seen type:DISKPART List DiskIf you have not yet attached your collection disk you will have totype:DISKPART Rescanand then List Disk after connecting it You need to establish a drivenumber eg disk 1 or disk 2 and so on for your collection diskOnce you have done this you will need to select this disk:DISKPART Select Disk 1and you may need to put it online:DISKPART onlineand then clear any readonly attributes:DISKPART Attributes disk clear readonlyThen identify the volume upon your collection disk you wish to imageto:DISKPART List Volumeand then select the volume:DISKPART Select Volume 1and then clear any readonly attributes:DISKPART Attributes volume clear readonlyNext - assign a drive letter:DISKPART assign letter=kYou should now be able to write an image to your collection disk Ifyou are getting the error "your disk is write protected" or similarthe problem most likely lies with the read only attributeGremlin 2The disk during the boot process prompts press any key to boot fromthe CD This behavior is not very desirable in a forensic boot CD Toprevent this from happening delete the bootfixbin file from theISOoot folder before creating your WinFE CDGremlin 3Encase will run happily from the disk but simply copying your Encasefolder from Program files will cause some problems with respect to theencase config files and the indexing and parsecache folders The wayround this is to create an X: drive on your local machine and createan WinFE folder within it Then install a new copy of Encase into thisfolder If you then copy the Encase folder from here into the theWinFE tools folder all the paths will be fineLinkshttp://wwwsvropscom/svrops/articles/winvistape2htmhttp://wwwdigital-detectivecouk/cgi-bin/digitalboard/YaBBplnum=1213944253IMAGEhttp://www.secuobs.com/revue/news/103561.shtmlhttp://www.secuobs.com/revue/news/103561.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - My current case had a number of lets say incriminating photographs storedat this location I was not sure what the WIA folder was I have foundthat WIA is an abbreviation of Windows Image Acquisition and is usedto allow graphics software to communicate with imaging hardwareThe {6BDD1FC6-810F-11D0-BEC7-08002BE2092F} part of the path is a classGUID which features in the registry keyHKLMSYSTEMCurrentControlSetControlClass{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}Microsoft use this key to store information about installed stillimage devices I searched the System registry hive for this class GUIDand found that this key contained details of Trust 360 USB 20SpaceCam It appears that this webcam has a snapshot button whichcauses the bundled Photoimpression software to cache pictures into theWIA folders The 0000 in the path appears to be used to distinguishthe device If another still image device is used it would use folder0001 and so onHaving checked the registry of a few other boxes I have foundreferences to digital cameras and scanners Possibly a good source ofevidenceThe moral of the story - search your suspects registry for any strangeGUIDs you come acrossIMAGEhttp://www.secuobs.com/revue/news/103560.shtmlhttp://www.secuobs.com/revue/news/103560.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - A Medion MDPNA150 sat nav came my way in an IIC case the other day Itdidn't have any IIC stored upon it but whilst I had it I thought Iwould look at the recovery of navigation data should one come my wayrequiring thisThe sat nav had a 256mb mmc card and it also had internal memory Likethe Navman's I looked at earlier the Median runs a Windows CE OS andthe internal memory could only be accessed via Mobile Device Centre inVista probably Active Sync will suffice but I did not test withthis The navigation software is Destinator As it turned out I foundonly one file of note on this particular device - Previousdat Thisfile contains the history of locations previously navigated to and wasstored on the memory card Destinator does create other files ofpotential interest but they seemed to be missing on this sat navThe format of Previousdat is of particular interest and differs frommany other sat navs in the form it stores latitude and longitudeco-ordinates Most others I have seen before store these values assigned 32 bit integers Within this file they are stored as a DoubleThe structure of file seems to be as follows There does not appear tobe a header The file starts with the first record and all recordsappear to be variable in lengthEach record begins with a type which I believe relates to the variousnavigation options The type is stored in unicode and in my limitedsample I saw:City-StreetZip-Streetname of a FavouriteThe type is terminated with hex 0000A number of other zero terminated unicode strings may follow relatingto House Number, Street, City and postcodeEach record contains two sets of longitude and latitude co-ordinatesstored one after the other I speculate that one set is actual and theother set is nearest road In my sample they were either very similaror the same Each longitude or latitude value is stored as a doublewhich requires 8 bytes therefore 32 bytes are required to store bothsets The two sets are followed by a further 16 bytes of data -useunknown, which completes the recordTo locate these co-ordinates I found it easier to count back from thestart of the following record The other problem to overcome is how toconvert the doubles to a decimal value Encase does not have a easyway to do this The data interpreter in Winhex can do this The hexeditor 0xED on a mac can also do this but rounds up to fewer decimalplaces than winhex20th November 2008 UpdateSubsequent to writing this up I examined a Goodmans device alsorunning destinator software I have written about it here There ismore information in that post I can supply an Enscript written by myfriend Oliver Smith over at Cy4or to parse out these records onrequestReferenceshttp://wwwmozoftcom/d3loghtmlhttp://wwweceuwaterlooca/~ece204/TheBook/02Numerics/double/completehtmlhttp://wwwgpsbabelorg/htmldoc-development/fmt_destinator_trlhtmlIMAGEhttp://www.secuobs.com/revue/news/103559.shtmlhttp://www.secuobs.com/revue/news/103559.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - Dell boxes both laptop and desktop seem to be more difficult to imageevery week We had a Dell Inspiron 530 midi tower with a Seagate 320GBsata hard disk submitted to us Our normal method of imaging thisdrive with a Tableau T35i write blocker and FTK Imager failed as thedrive seemed to turn off after about ten minutes An attempt with aTableau T3u and FTK Imager also failed Both Tableau write blockershad the latest firmwareNext we tried to image the drive in situ by utilising a Helix 19aboot disc Despite trying a variety of cheat codes we could not getthe Helix disc to workSo I decided to try out Windows FE in anger Step one involved tryingto identify the necessary drivers to build into the WinFE iso Iplumped for the relevant Intel Matrix Storage Manager sata driver forVista which downloads as a self extracting zip file R154092exe andloaded the two inf files into my WinFE iso I also decided to add achipset driver and downloaded the relevant Intel Chipset softwareInstallation Utility This also downloads a self extracting zipR154069exe however when you run it as well as extracting a largenumber of drivers it also on the Vista side my Macbook Pro at leasttried to begin an installation which I canceled The chipset utilitycontains drivers for a large number of chipsets The Inspiron 530 hasan Intel G33 chipset so I loaded g33q35inf into my WinFE isoWith the drivers loaded I added my imaging tool In my earlier WindowsFE posting I alluded to FTK Imager not working The author of theWinFE paper Troy Larson kindly advised me that one of his colleagues -Andrew Choy had been able to get FTK Imager to work In addition tothe dlls identified by Access Data as being required in the samefolder as the FTK Imagerexe, a dll oledlgdll fromC:Windowssystem32 needs to be addedWe added another sata drive onto a spare sata port within the Inspiron530 and booted to the Windows FE boot disc Some Dell boxes includingthis one provide a boot menu by holding down F12 After following theguide to using Diskpart in my earlier posting and assigning a driveletter to the additional sata collection drive we utilised FTK Imagerto image the drive in record time We imaged to Encase evidence fileswith maximum compression and the whole process completed includingverification in less than four hours Windows FE worked like a dreamIMAGEhttp://www.secuobs.com/revue/news/103558.shtmlhttp://www.secuobs.com/revue/news/103558.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - Yet another Navman sat nav has come my way - an F20 versionID 4101029BuildTime 2007-02-12, 09:38:57 and once again a different approach isrequired to access the relevant data files The last Navman I lookedat was a Windows CE device that became accessible using Mobile DeviceCentre in Vista I have not been able to access this device the sameway and I believe the underlying OS is Linux based This site alsostates that the F20 is not running Windows CE The case markings alsodo not disclose the precise model within the F series range There arehidden service menus that will provide model and firmware informationthat are accessible by holding down the power and menu buttonstogether when powering onThere is an SD Card slot which on the device I examined was notpopulated The data was stored internally I was not able to accessthis device as a removable USB storage device despite tracking down adriver The only option left to me was to identify the storage withinthe device - luckily I discovered that the device has a micro SD cardthat is accessible without resorting to a full disassembly Thefollowing pictures show how to access the cardThe memory card was formatted FAT16 and within the Navman/Systemfolder I identified three notable files:* Recentdat* Favver4dat* RoutedatRECENTDAT stores up to thirty locations The locations may be-destinations that the user chose to navigate to-they may be the location that the unit was at when it was turned on-or the location the unit was at when the user chose to navigate to anew destinationThese locations are stored in records of 520 bytes in length Eachdestination has its Lat/Long coordinates stored in 8 bytes starting atRecord Offset 507 These are decoded by bookmarking in Encase as a 32bit integer The resulting values need to be divided by 100,000 Inthe UK Latitude will begin in the range 49-59 and is decimallynotated Longitude is in the range -5 to +16 ish When bookmarking asa 32 bit integer Longitude is shown first and will often be a negativevalue ie anywhere west of GreenwichFAVVER4DAT possibly stores up to 200 user entered favouritedestinations These favourite destinations are stored in records of1508 bytes in length Each destination has its Lat/Long coordinatesstored in 8 bytes starting at Record Offset 352 These are alsodecoded by bookmarking in Encase as a 32 bit integer and dividing eachvalue by 100,000 I also established that the first location storedwithin this file was the User inputted Home locationROUTEDAT I speculate is used to store the origin of the lastnavigated journey Coordinates can be found at record offset 507however in this particular device no data was found in this fileI have an Enscript kindly coded by my friend Oliver Smith over atCy4or to parse the recentdat file Please email me if you need itAlong with the F20 I have also examined a Navman iCN 330 This unit issimilar to the Navman iCN 310 I wrote about earlier This device hadit's notable files stored upon an SD card also Notably all the flashmedia cards I have examined that originate from Navman devices did notcontain any relevant data within unallocated clusters This suggeststhat in some cases a manual examination ie photograph displaywhilst device is turned on may sufficeAnother issue I have encountered is how to test on these devices OnTomToms it is possible to clone the memory cards and use the clonedcard for testing This is not possible with the Navman devices I haveseen When you run the Navman with the cloned card you quickly receivean eror message No Map Data or similar It appears that Navman hassome anti copying features built in that utilise the flash card's CIDnumber which I believe is stored within a non host accessible area ofthe flash card As each card has a unique CID number cloning isimparedReferenceshttp://navmanunlockedwikispacescom/Unlockhttp://wwwsdcardorg/about/memory_card/pls/http://duffdk/navman/http://wwwgizmondoforumscom/forums/indexphpshowtopic=5366IMAGEhttp://www.secuobs.com/revue/news/103557.shtmlhttp://www.secuobs.com/revue/news/103557.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - We upgrade our forensic workstations every eighteen months or so havejust taken delivery of four shiny new ones This time I decided thatthe time had come for us to enter the brave new world of 64 bitoperating systems I have read many peoples experiences of this onDigital Detective, Forensic Focus and so on and was expecting a numberof difficulties However the driver for change is utilising 8gb ram soXP 64 bit was specified To be on the safe side I had the machinesbuilt in a dual boot configuration with XP 64 bit on one partition andXP 32 bit on another As an additional safeguard on the 64 bit side Iinstalled VMWare Workstation and created an XP 32 bit VMSo if it helps anyone here is a list of what works and what doesn'tXP 64 Software installations64 bit programsEncase 6112 x64Encase installed OK Help About shows that the PDE,VFS, EFS and Fastbloc SE modules are installed and I have successfullytested PDETomtologyTomtology x64 1162, NET 35 Redistributable and the keylockdongle drivers all installed and workinghttp://forensicnavigationcom/#/downloads/45279590367Ziphttp://downloadssourceforgenet/sevenzip/7z460-x64msiUltramonhttp://wwwrealtimesoftcom/files/UltraMon_271_en_x64msiFirefoxhttp://wikimozilla-x86-64com/DownloadCodeMeterCodeMeter Runtime 330a is needed for the FTK codemeter dongleGimp 254http://downloadssourceforgenet/gimp-win/gimp-254-r26790-x64-setupexemodtime=1219882476etbig_mirror=032 bit programs that work within the 64 bit OSEncase 6112 32 bit versionThe 32 bit version installs and runs OKAccess Data FTKI had hoped to upgrade to FTK2 but a 64 bit version hasnot been released I did however decide to transfer our licences fromthe green keylock dongle to the Codemeter dongle There are detailedinstructions on how to do this within the FTK2 box I used an internetconnected laptop with the latest version of Licence Manager installedto carry out the transfer Once the licences were on the codemeterdongle I installed CodeMeter Runtime 330a 64 bit onto the XP 64 bitbox and then inserted the dongle It was successfully recognized FTK181 and Registry Viewer 153 have been installed and they work OKhttp://accessdatacom/downloadshtmlMicrosoft Office 2007The office programs are 32 bit but are designedto work with a 64 bit MS OSVFCI have installed VFC 1243, the green keylock dongle drivers andVMWare Diskmount Utility All seem to work OKhttp://wwwvmwarecom/download/eula/diskmount_ws_v55htmlC4PC4P v334 runs without issue However some work is needed to getthe C4P graphics extractor enscript runningFor Encase v6 64 bit running on XP 64 bit install the 64 bit MySQL351 ODBC connector driver found athttp://devmysqlcom/downloads/connector/odbc/351html#winx64and also a MS hotfix found athttp://wwwmicrosoftcom/downloads/detailsaspxFamilyID=000364db-5e8b-44a8-b9be-ca44d18b059betdisplaylang=enThe latest C4P v4 graphics extractor enscript contains a mySQLdatabase connection string which needs modification if you are usingmysql The string needs to be edited to read:ConnOpen"PROVIDER=MSDASQL;DRIVER={MySQL ODBC 351 Driver};SERVER=" +ComserverName + ";DATABASE=" + DbName + ";" +"UID=c4p_user;PASSWORD=password;OPTION=3"NetAnalysisNetAnalysis 138 beta 6 is running OKIrfanviewIrfanview 420 is a running OKSaminsideSaminside v2571 is running OKIsobuster 19 ProIsobuster 19 Pro works OKVarious other utilities such as PSPad, FileAlyzer, WRR and WFA arealso working OKThings that did not workWell not much really The Microsoft powertoy picture resizer does notwork but is adequately replaced withhttp://adionsoftnet/fastimageresize/IMAGEhttp://www.secuobs.com/revue/news/103556.shtmlhttp://www.secuobs.com/revue/news/103556.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - Some of you may be thinking that this blog has stopped being a computerforensics blog and is now only covering sat navs It seems that waylately, but it is just that my computer cases are all run of the millwhilst sat navs are nearly always new and exitingThe Sony NV-U50 G sat nav I looked at is running Sony PersonalNavigation System version 106 software within Windows CE It has512mb of internal memory and no external flash media I accessed itvia Mobile Device Centre in Vista probably Active Sync will sufficebut I did not test with this and discovered a My Flash Disk volume asnormal A folder named Sony will be accessible and within the NAV-Usub folder the following notable files can be found:* recenttxt* favouritestxt* prefsiniAll three files are plain textprefsini is used to store user preferences but also contains threeuseful values:* hometarget* lasttarget* LastVisibleAreahometarget contains the postcode and latitude and longtitudecoordinates of the user set home location lasttarget was notpopulated on the device I examined but I understand from colleaguesthat it can contain the last navigated to location Both these valuescomprise of seventeen fields separated by the pipe symbol |LastVisibleArea contains the lat/long coordinates of the bottom leftand top right corners of the last map displayed on the device prior tobeing switched off I had seen that the manual for the devicecontained the note:The Sony Personal Navigation System always opens with the screen thatwas active at the time you switched off the devicerecenttxt and favouritetxt contained recently navigated to locationsand user stored favourite destinations respectively Each locationrecord comprised of seventeen fields separated by the pipe symbol |in both files allowing them to be imported into an excel spreadsheetusing the text data import wizardExample of a single favourite recordGFRIEND|-|48|12366|-|-|SW1 1AA|-|-|-|-|-0142076|5150107|-|-|-|-|Field 3 in most cases contained the value 48 which I understand to bethe Country Code used by Sony/Navteq for the UK, Field 4 had in somecases a five digit number beginning with the digits 12 I speculatethat these fields have something to do with the RDS/TMC facilityavailable with this device Fields 12 and 13 contained the Longtitudeand Latitude coordinates of the location record stored in decimalnotation Fields 16 and 17 if populated contained a second set ofLongtitude and Latitude coordinates which I can only speculate may bejourney originsThe device can also store pre-planned itineraries and these are storedwithin files with a rte file extension in the Sony/NAV-U/Routesfolder These files are plain text formatted the same way asrecenttxt and favouritetxt By carrying out a live examination of the device most the data abovecan be ascertained, however where a user has allocated a name to afavourite or itinerary only the allocated name will be displayed - notthe underlying address and lat/long coordinatesUPDATED 17th December 2008I have been asked whether the order of the entries in Recenttxt hadany significance I have carried out some further testing andestablished:i Recenttxt will contain a maximum of thirty entriesii If the entry is generated by a user choosing to navigate to aFavourite via the Favourites menu button the display name will bestored along with other location information within Recenttxtiii The most recently entered location is recorded lastiv Once there are thirty entries within Recenttxt when a newlocation is added the oldest record at the top of the list is deletedAn exception to this is if a new location duplicates an entry alreadystored in Recenttxt the older entry is deleted wherever it wasstored in the list and a new location appended to the end of thelistI also had another look at the secondary lat/long values and I am nowof the view that they DO NOT contain journey origins During testingall the values I was able to populate in these fields were fairly nearto the location chosen to navigate to I could not however discerntheir relevanceIMAGEhttp://www.secuobs.com/revue/news/103555.shtmlhttp://www.secuobs.com/revue/news/103555.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - A HP media centre laptop came through our lab recently Its main OS wasXP Media Center edition However it appeared to have another XP OSinstalled on a separate 1GB partition This was a case where thesuspect was suspected of hiding stuff and regularly re-installing hisOS to cover his tracks - so this second OS was of interestEncase listed three partitionsMounting the drive PDE and looking at the disk in Disk ManagementshowedThe Windows Initialise case module reported the following for the OSon the 1GB partitionThe 1GB partition has a Partition Type of D7A quick google began to throw some light on the matter It seems thatthe laptop has HP Quickplay 23 installed This technology allowsusers to access multimedia disks without booting into the mainoperating system The version of XP on the partition with partitiontype D7 is XP embedded This OS facilitates the quickplay functionLater versions of HP Quickplay do not use this methodIt seems that a number of other manufacturers use the D7 partitiontype for similar purposesReferenceshttp://enwikipediaorg/wiki/QuickPlayhttp://wwwgoodellsnet/dellrestore/mediadirecthtmhttp://wwwasifismcom/installing-hp-quickplay-on-your-laptopnotebook-vista-xp/IMAGEhttp://www.secuobs.com/revue/news/103554.shtmlhttp://www.secuobs.com/revue/news/103554.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - This device runs destinator software within a Windows 42 CE OS and issimilar to the Medion MDPNA150 I looked at earlier It has an externalSD card slot which was not populated on the one I looked at It alsohas internal flash memoryI accessed the device via Mobile Device Centre in Vista and copied offthe contents of the ResidentFlash volume At the pathDestinatorAppsDestinatorUK_Ireland I found Previousdat This filecontains Recent Locations which are locations that the user chose tonavigate toI have deconstructed the records found within PreviousdatKey click on table to view larger imageExample Records click on records to view larger imageEach record contains two sets of longitude and latitude co-ordinatesstored one after the other I speculate that one set is actual and theother set is nearest road In my sample they were either very similaror the same Each longitude or latitude value is stored as a doublewhich requires 8 bytes therefore 32 bytes are required to store bothsets The two sets are followed by a further 16 bytes of data -useunknown, which completes the recordTo locate these co-ordinates I found it easier to count back from thestart of the following record The other problem to overcome is how toconvert the doubles to a decimal value Encase does not have a easyway to do this The data interpreter in Winhex can do this The hexeditor 0xED on a mac can also do this but rounds up to fewer decimalplaces than winhexI can supply on request an Enscript written by my friend Oliver Smithover at Cy4or that will parse out these recordsIMAGEhttp://www.secuobs.com/revue/news/103553.shtmlhttp://www.secuobs.com/revue/news/103553.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - Encase version 6 now includes considerable functionality in recoveringInternet History records for a number of browsersIn a recent case using v6121 I ran a search for internet historywith the Comprehensive search option selected My results includedrelevant hits in unallocated clusters which Encase attributed toMozilla History/Forms The results are recorded within the EncaseRecords tab and when highlighting a record some data was highlightedin the view pane which made me scratch my head - and luckily loosensome cobwebs in a long ago abandoned area of my brain What was Encaseshowing me - I wasn't sure but my brain was telling me it wassomething to do with MorkClick on screenshot 1 to see a larger imageMy suspect was using Firefox version 18 Firefox can save subject touser configuration information entered into web forms and the searchbar to make form filling and searching faster This information issaved in a file known as formhistorydat Encase had found data withinunallocated that was a fragment of a deleted formhistorydat file Inthis version of Firefox formhistorydat contained a Mork databaseEncase had highlighted in the view pane what I will loosely refer toas the address of the data that it had parsed out8^83^83^82^8ATo understand this better we need to look more closely at all the datain the database Because the hit was in unallocated I needed to findthe start of the deleted formhistorydat file The file signature ofthe file is highlighted in the screenshot belowClick on screenshot 2 to see a larger imageso I scrolled up in the view pane, found this header and swept down tothe footer which is the } after the last address and exported outthe data as a fileClick on screenshot 3 to see a larger imageOpen the file with Notepad and find/replace all the $00 strings withan empty string The file now looks a lot more readableClick on screenshot 4 to see a larger imageIn the example we are working through the address we are interested inis8^83^83^82^8Awhich can be seen shown in red at the bottom of Screenshot 4 aboveThis address is a row within the Mork database The row is delimitedwith open and close square brackets and is made up of a Row ObjectID followed by a series of cells delimited by open and close brackets The cells contain a column name and a valueThe column names are defined within a dict delimited with shown ingreen at the start of Screenshot 4 above It can be seen that twocolumn names are relevant here name and value, given object ids of 83and 82 respectivelyThe values are defined within the next dict down The one relevant toour address are shown in red8^83^83^82^8Adecodes to8^Name^searchbar-history^Value^vmware fusionThe Name column contains the type of record - searchbar-history meanswhat it says on the tin, other values may relate to various fieldsfound on web page forms The query field on the Google Firefox startpage is represented by q Encase does not report these records particularly well I chose toexport relevant records into a spreadsheet and manually add thephysical sector and sector offset of each rowReferenceshttps://supportguidancesoftwarecom/forum/showpostphpp=115379etpostcount=2http://wwwmozillaorg/mailnews/arch/mork/primertxthttps://developermozillaorg/en/Mork_StructureIMAGEhttp://www.secuobs.com/revue/news/103552.shtmlhttp://www.secuobs.com/revue/news/103552.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - Paint Shop Pro has a slightly longer title nowadays From a forensicperspective the older version had a thumbnail cache stored within jbffiles Tim Coakley wrote a tool for parsing the contents out Istumbled across this new version when I saw some subfolders in mysuspect's My Pictures folder entitled 20080102 and a subfolderentitled Thumbs at the path C:Documents and SettingsusernameLocalSettingsApplication DataCorelThumbs This folder had a number ofjpgs within it with filenames in the format yyyymmddjpgThe software can be installed as a trial It has two components thatleave good evidence - an Organizer that creates a thumbnail databaseof selected folders by default the current users C:Documents andSettingsUsernameMy Pictures, C:Documents and SettingsAll UsersMyPictures and My Corel Shows and the Corel Photo DownloaderOrganizerWhen the program is first run it will catalogue all supported picturetypes in the default folders This allows the user to view a thumbnailgallery of the catalogued folders within the program The thumnailsare created and stored at the path:C:Documents and SettingsUsernameLocal SettingsApplicationDataCorelThumbsThese catologued thumbnails retain the filename of the originalpicture Metadata is stored in a database imagedbdbCorel Photo DownloaderThis utility was responsible for creating some good evidence in myrecent case It is installed as part of Corel Paint Shop Pro Photo X2and is intended to automate the download of photographs from cameras,flash media cards and CDs The following dialogue box shows therelevant configuration settings:Photos downloaded with this utility form the folders and files I hadfoundThumbnails of them are catalogued as part of the Organizer function -a function your suspect may be unaware ofThumbnail issuesWhen Coral Paint Shop Pro Photo X2 is runningthumbnails are pruned if the underlying source folders/files aredeleted However if the program is not run after the underlying sourcefolders/files are deleted the thumbnails remain In my case it appearsthat the trial expired which allowed a considerable number ofthumbnails to remain at the path C:Documents and SettingsusernameLocalSettingsApplication DataCorelThumbsImagedbdbBoth the organizer and the photo downloader utilise aSQLite3 database to store metadata in relation to the cataloguedpictures The database can be viewed using the SQLite database browserIt is possible to walk through the database to establish the originalfilenames of any thumbnails and the source folder Other usefulinformation is stored in the database including program configurationIn my case the date of download was usefulFigure 1Details pictures downloaded in this case from a casio camera Thehighlighted picture has been given an image ID number - 5210 and has aDownload ID number 1Figure 2Image ID 5210 has been allocated the filename 20090129_3jpg and isstored in Folder 851Figure 3Folder 851's entry detailing the folder name and pathFigure 4Showing Download ID number 1's download dateIMAGEhttp://www.secuobs.com/revue/news/103551.shtmlhttp://www.secuobs.com/revue/news/103551.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - An MLAT request brought CD-R to my door recently The OIC informed methat the CD contained a Yahoo mailbox but wanted my help because hecould not read them I found that the CD contained a targz fileOnce this archive was unpacked I saw it contained two very large textfiles These files were generic Mbox files The next problem was howto view the contents I found that Apple Mail would happily importMbox files File/Import Mailboxes however I live in a mainly windowsworld so needed a Windows method for the OIC to preview the emailsThunderbird came to mind, however although this program uses the mboxformat for its mailboxes it does not offer an easy way to import themI did track down an extension to Thunderbird that provided thisfunctionality but it only worked on one of my two mbox files I alsofound that Opera 9 would also import my mbox filesThe problem with both Thunderbird and Opera is that the boxesavailable to the OIC in this case, and our customers in general,mostly do not have these programs installed Ideally a way of gettingthe email messages into Outlook Express would be the best bet Thesolution to this is provided by using the Mid Michigan ComputerForensics Group's M2CFG Yahoo Email/Text Parser This program parsesout the email messages into eml files which can be dragged intoOutlook Express and a number of other Email clientsAs it turned out the two mboxes I had extracted for the OIC were sofull of emails with attachments that it was too complicated for him toprocess efficiently So they came back to me to investigate I addedthe mbox text files into Encase v6121 and searched for email withthe mbox option selected which resulted in Encase parsing out theemails and attachments very well Reporting them was another matterIMAGEhttp://www.secuobs.com/revue/news/103550.shtmlhttp://www.secuobs.com/revue/news/103550.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - We are lucky in our lab that our workstations are upgraded on aregular basis so once in use we don't often make many changesThe most important bits of my current spec are as follows:1 Supermicro X7-DWA-N fitted into a Supermicro CSE-733TQ-645chassis2 Two Intel Xeon X5482 processors3 16GB DDR2 800 Ram4 Western Digital 300GB VelociRaptor10,000 rpm hard drive for theOS5 3 x 1TB Samsung HE103UJ Spinpoint F1 hard drives in a RAID 0array6 Microsoft XP 64 bit7 256MB ATI FirePro V3700 GPUAt one time our primary forensic software Encase would max out theprocessor when carrying pretty much any process With the advent ofmulti-core dual processors we aim to max out one core which on my boxis 13% cpu utilisation in task manager As processors get faster andfaster I have noticed that often the CPU core is not maxing outSomething else is slowing us down We store our Encase evidence fileson the Raid 0 array and just before someone posts a comment about thelack of data resilience etc, the way our lab is set up all the dataon my Raid 0 array is mirrored elsewhere We do this for speed andcapacity When Encase and most other forensic utilities for thatmatter is processing it has a voracious appetite for data Just lookat the Read bytes value in Task Manager The multi-core processorsallow us to run other forensic programs FTK, Netanalysis hstex etcetc along with Encase, we can even run other instances of Encase, andbecause we can - we do The net result of all these programs runningis that they compete to read data from the Raid 0 array in my caseand from wherever you store yours in yours - the net result onceyour data storage is maxed out is things slow down It follows thenthat performance can be increased by having faster data storageOne way to achieve this would be faster hard drives We use sata harddrives for capacity reasons and to an extent cost SAS hard drives arefaster but don't provide the capacity So as things stand three harddrives in a Raid 0 array was the best that could be done I decided tosee how I could make some improvementCurrently the three hard drives and the OS drive connect to theIntel ESB2 raid controller integrated on the motherboard Conventionalwisdom would have it that by adding a fourth hard drive to the raid 0array would speed things upHD Tach details an average sequential read speed of around 200 MB/sfor a three drive array utilising the default stripe size 128kb withNTFS formatted with the default cluster sizeIMAGEAdding a fourth drive slowed the sequential read speed to around 180MB/sIMAGEI tested a variety of different stripe sizes and aligned thepartitions but came to the conclusion that the Intel ESB2 controllerjust did not scale up to four drives very well The arrays werecreated via the utility accessed via the controller bios during bootup This utility is very basic and does not allow much configurationIntel also provides a Windows utility called Intel Matrix StorageConsole When running this utility I found that by default VolumeWrite-back cache was disabled Enabling it made a significantimprovementIMAGEConventional wisdom has it that a hardware Raid controller wouldimprove performance over the Intel ESB2 and in my testing this seemsto be the case I have used an Areca 1212 PCI-E raid card and achieveda sequential read speed of over 600 MB/sIMAGEThis array has four 1TB sata hard drives with a 64kb stripe, ispartition aligned at 3072 sectors and has one NTFS volume with thedefault cluster size Using Syncback to write to the array from ourfile server across a copper gigabit ethernet network produces somepretty impressive network utilization statsIMAGEIMAGEhttp://www.secuobs.com/revue/news/103549.shtmlhttp://www.secuobs.com/revue/news/103549.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - BackgroundFacebook has a built in instant messaging facility which has grown inpopularity along with the Facebook social networking site itself Manycases involve potential grooming offences in which the use of instantmessaging needs to be investigatedThe instant messaging facility creates a number of artefacts which areeasily found and I know have been commentated on elsewhere Thepurpose of this blog post is to suggest a methodology to automate thediscovery and reporting of Facebook messagesFor those who have not looked at this area in detail yet messages arecached in small html files with a file name P_xxxxxxxxhtm or txtThese messages can be found in browser cache, unallocated clusters,pagefiles, system restore points, the MFT as resident data andpossibly other places It is possible for the messages to be cachedwithin the main Facebook profile page although I have never seen themthere - the main facebook page does not seem to be cached that oftenAn example of a message is shown below:for;;;{"t":"msg","c":"p_1572402994","ms":{"type":"msg","msg":{"text":"AnotherMessage","time":1237390150796,"clientTime":1237390150114,"msgID":"3078127486"},"from":212300220,"to":1123402994,"from_name":"MarkPPPPPP","to_name":"RichardXXXX","from_first_name":"Mark","to_first_name":"Richard"}}The bulk of the message is in fact formatted as JavaScript ObjectNotation normally referred to as JSON The format is a text based andhuman readable way for representing data structures The timestampsare 13 digit unix timestamps that include milliseconds - they can bedivided by 1000 to get a standard unix timestampAlthough keyword searches will find these messages they are difficultto review particularly if you are only interested in communicationbetween selected parties Having found relevant hits you then have tocreate a sweeping bookmark for each one For these reasons I followthe following methodologySuggested Methodology* Create a Custom File Type within the Encase Case Processor FileFinder module entitled Facebook Messages using the Header "text":"and the footer }} making sure GREP is not selectedIMAGE* Run the file finder with the Facebook Messages option selected* When the file finder completes you will have a number of textfiles in your export directory providing there are messages to befound* These text files are in the form of the example above They do nothave Carriage Return and Line Feed characters at the end of thetext We need to remedy this by utilising a DOS command at thecommand prompt* At the command prompt navigate to the directory containing yourexported messages please note Encase creates additional subdirectories beneath your originally specified directory* Then run the following command:FOR %c in *txt DO Echo%~nctxtThis command adds a Carriage Return and Line Feed to the end ofthe extracted message* Next we want to concatenate the message text files into one fileusing the command at the DOS prompt: copy *txt combinedtxt* Alternatively create or email me for a batch file that executesthese two commands direct from windows* An additional file combinedtxt will be created in your exportdirectory* Launch Microsoft Excel and instigate the Text Import Wizardspecifying Delimited with the Delimiter being a comma and the textqualifier " Put the data into your worksheet or cell J3 of my pre-formattedworksheet* All that's needed now is to tidy up the worksheet with some Excelformulas the full details of which can be found within my examplepre-formatted worksheet The formula to process the time valueswhich are Unix time stamps is RIGHTK2,13/1000/86400+25569where K2 is the cell containing the source time data* Perform a sanity check and remove obviously corrupt entries* It can be seen below that after applying a data sort filter youcan sort by time or userIMAGE* The spreadsheet also allows you to de-duplicate the foundmessages In my recent case over half the recovered messages wereduplicates In Excel 2007 these duplicate rows are easilyremoved Data/DataTools/Remove Duplicates In Excel 2003 anadd-in called The Duplicate Master will do this for youFurther ThoughtsNon Encase users may be able to use an alternative file carver egBlade to carve out the messages I am sure that the header and footercould be refined a bit to reduce false positives, however for me theratio of legitimate versus false positives is OK UPDATE 22nd April2009 - non encase users may wish to look at my more recent postI have the pre-formatted spreadsheet in template form Please email mefor a copy with a brief explanation of who you are - thanksTo further investigate the data you recover you may wish to check outhttp://wwwfacebookcom/profilephpid=xxxxxxx Just substitute thexxxxx with the User ID's you recoveredEnscript MethodI have collaborated with Simon Key and now have an enscript to parseout JSON objects including messages It outputs to a csv spreadsheetand in my tests parsed 160GB in about an hour It might not be astolerant of corrupt strings as the method detailed above The scriptwill only run in 613 or newer I have a template that tidies up theformatting of the csv- email me if you want a copyReferences and thankshttp://coderrrwordpresscom/2008/05/06/facebook-chat-apihttp://videogooglecom/videoplaydocid=6088074310102786759http://jsonorg/http://enwikipediaorg/wiki/JSONhttp://wwwwilsonmarcom/datepgmshtm#UNIXStampThanks to Glenn Siddall for sparking my interest and providing me withsome notes of his researchThanks to Mark Payton for his assistance in researching thisIMAGEhttp://www.secuobs.com/revue/news/103548.shtmlhttp://www.secuobs.com/revue/news/103548.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - The forensics community has benefitted from the free Linux forensicdistro Helix3 for some time This distro was developed by Drew Faheyand distributed via e-fensecom archived Helix 3 website I suppose,like many free things, the issue of how to you support it and developit when you are not making money from it became an issue for e-fenseI was under the impression that a revenue stream was available viaHelix3 training courses run by CSI Tech in the UK I know that bothNick Furneaux and Jim Gordon were very busy with these courses, andhaving attended one myself, I thought they were a great successAnyhow it seems that training provision wasn't enough Late 2008e-fense invited e-fense helix forum members to make donationsUnsurprisingly take up wasn't that great This resulted in a slightlyhectoring email from e-fense announcing that Helix3 was now onlyavailable to those who subscribed for access to their forum Thesubscription is around US$20 per month So be it but as someone whohas already paid circa US$1000 for a training course to use a productI cannot now download without subscription I am left feeling slightlydisappointedNothing stands still in this arena however I have posted in the pastabout WinFE and some subsequent comments led me to a Grand StreamDreams blog post written by Claus Valca He referred to two freeforensic Linux distros:* DEFT Linux* CAINEPerhaps one of these is the new helixIt seems one or two others have commented on the same subject -itseems they are not planning to subscribe eitherI noticed a bit late in the day that there is an extensive thread overat Forensic Focus about this issue alsoIMAGEhttp://www.secuobs.com/revue/news/103547.shtmlhttp://www.secuobs.com/revue/news/103547.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - As has been widely reported elsewhere many Seagate Barracuda hard diskdrives have faulty firmware that causes them to effectively freezeIn our lab we have 12 of the affected Seagate Barracuda 720011 1TBdrives and 50 Seagate ES2 1TB drives Two of the 720011 have failedwith symptoms that suggest that faulty firmware was the cause I haveflashed the firmware of all of the affected working drives and hopethat I can look forward to a long fault free periodOne of the failed 720011 drives was one third of a Raid 0 array inone of our forensic workstations This workstation needed an OSreinstallation onto a separate single drive and temporarily somedata on the OS drive normally backed up to the Raid only existed onthe Raid During subsequent software installations a number of rebootswere required triggering the firmware bug and a failed raid OhbotherNormally data on our Raid 0 arrays is backed up but due to theaforementioned OS reinstall there was a small amount of data thatlost I therefore had to find a way to unfreeze the locked SeagateBarracuda A considerable trawl of the internet led me to this postGradius2 details a fix involving a significant amount of down anddirty electronics and low level hard drive programming Not having allthe necessary adapters/serial cables etc led me to call Disk LabsThey quoted £1000 - that was a no go then Luckily Hugh Morgan atCy4or successfully repaired the drive broadly following Gradius2's fixfor significantly less I reintroduced the drive to the two otherdrives in the Raid 0 array and Bob's Your UncleIMAGEhttp://www.secuobs.com/revue/news/103546.shtmlhttp://www.secuobs.com/revue/news/103546.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - This device has two memory chips hard wired onto the internal pcb,therefore the only regular means of accessing this memory is via theUSB port These sat nav devices will act as mass storage devices whenconnected via USB I imaged one whilst connected to a Tableau USBwrite blocker Please note that the time the device is switched on isrecorded within currentgpx referred to belowThere are few human readable files most notably currentgpx This filecontains the users home location and user selected favourites alongwith the location of a number of Garmin offices If a user saves afavourite from a location on a map the favourite will be entitled 001,002 and so onThere are a number of ways to investigate the contents of currentgpxEffectively it is an xml formatted file which I use Microsoft XMLNotepad 2007 to review You can also use a utility such as EasyGPS oropen the file with Google EarthTo report the contents of currentgpx I use Microsoft Excel 2007 Inorder to do this successfully change the file extension to xml and usethe xml data import facility Data/ From Other Sources/ From XML DataImport allowing Excel to create the schema You will end up with anicely formatted tableRecently Found locations unfortunately do not appear to be savedwithin the user accessible memoryThe hidden service menu of the device can be accessed by turning onand then holding a finger on battery symbol on screen for 10 secondsIt is possible once in this menu to interface with the device via USBwithout it behaving as a mass storage device Garmin USB drivers arerequired to do this I am not sure whether this will be usefulforensically at any stageReferenceshttp://enwikipediaorg/wiki/GPS_eXchange_FormatDownload nuvi 200 manualhttp://wwwtechonlinecom/showArticlejhtmlarticleID=210601020IMAGEhttp://www.secuobs.com/revue/news/103545.shtmlhttp://www.secuobs.com/revue/news/103545.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - The value of cookies and other internet history related artifacts iswell known Not as widely commentated on are Local Shared Objectscreated by Adobe Flash Player They have a sol file extension and onthe vista box I am looking at at least they are stored at:Usersyour userAppDataRoamingMacromediaFlashPlayer#SharedObjectsThese Local Shared Objects are data files that can be created on acomputer by visited websites and in many respects are similar tocookies It appears however that the conventional forensic software Iuse to analyse internet history ignores these files I use Netanalysisand Encase v6 Comprehensive Internet History searchTo parse sol files into a more readable form I use the SharedObjectReader plugin of FlashDevelop3Referenceshttp://wwwadobecom/products/flashplayer/articles/lso/http://enwikipediaorg/wiki/Local_Shared_ObjectIMAGEhttp://www.secuobs.com/revue/news/103544.shtmlhttp://www.secuobs.com/revue/news/103544.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - My blog post about facebook chat generated a lot more email thanusualIn particular Jad Saliba wrote about a program he has written tosearch for and report on facebook chat Jad's program is calledInternet Evidence Finder and essentially at this time it searches forFacebook chat, Facebook pages, Yahoo chat and MSN chat Jad points outthat the program may be useful in a non Encase shop and I agree Infact it will be useful anywhere as it did a very good jobI have had some fun testing it today and found that it parses all themessages that my two previously documented methods had found I usedthe program by mounting the drive image I wished to search with EncasePDE and then running the program across the mounted drive On my boxthe search ran at a speed of about 27 MB/sec The resultingspreadsheet was nicely formatted and gave the Physical Sector of eachhit Jad's program is freeware and can be found athttp://wwwjadsoftwarecomWith respect to MSN chat and the other chat clients Jad's website dealwith what can be achieved In testing I am running right now with MSNa large number of false positives have been found however this isprobably the nature of the beastNow before someone mentions tool validation my view is that I don'tvalidate my tools - I validate my results Generally I do this withdual tool verification as in the example aboveTill next timeIMAGEhttp://www.secuobs.com/revue/news/103543.shtmlhttp://www.secuobs.com/revue/news/103543.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - Most forensic practitioners will prefer to use hardware write-blockersover software However when the device you wished to image only had afirewire interface the choice was limited Hardware write-blockers forfirewire didn't exist Now somewhat late in the day Tableau haveintroduced the Tableau T9 This write-blocker will allow you to imagefirewire external storage drives as well as Apple Macs booted intotarget disk mode Given the increase of Macs submitted to our lab Ican see the T9 becoming very useful Data Duplication will sell the T9in the UK for around £240IMAGEhttp://www.secuobs.com/revue/news/103542.shtmlhttp://www.secuobs.com/revue/news/103542.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - When we upgrade our Forensic Workstations we cascade the oldermachines onto administrative and imaging tasks One particular exForensic Workstation had supported a tape drive for a year or two butnow was about to become totally redundant Instead of suffering thisfate I decided to dedicate it to running Helix The box itself is aSupermicro chassis sporting a Supermicro X6-DAL-TG motherboard, twinXeon Nocona 34 ghz processors, 2GB ram and a hot swap drive bayI had read Andre Ross's blog post Installing Helix 2008R1 and JessGarcia's How to install Helix to Disk webpage and decided thatinstalling to hard disk was the way to goThe process I followed to do this successfully guided by Andre Ross'spost in the main was:1 Equip box with an unformatted wiped hard disk - using apartitioned with ext2 and linuxswap disk caused the installationroutine to hang2 Boot box to Helix 2008R1 CD and commence installation by going toSystem-Administration-Install3 At the point the installer hangs Who are you screen clickcancel and then quit4 Commence installation routine again and create a user - I calledmine Helix5 Configure Network Adaptor to connect to the internet viaSystem-Administration-Network6 Launch Update Manager via System-Administration-Update Managerand update all packages7 Applications-Forensics et IR-Root Terminal:~#apt-get install smbfs:~#apt-get install winbindPart 1 of the job is done A little bit of configuration is needed tomake the machine more usable in it's main role as an imaging machineI am not a Linux guru so apologies for the Janet and John approach forthose that are Also my imaging machines are in a secure environmentand not normally connected to the internet so I felt relaxing securitya little may be OKRelaxing Security1 System-Administration-Login WindowOn the Security tab you may wish to enable Automatic Login for theHelix user2 Applications-Forensics et IR-Root Terminal3 :~# nano /etc/sudoers4 Use arrow keys to scroll to end of file then typeHelix ALL=ALL NOPASSWD: ALLpresuming helix was the name of the user account you created, ifnot substitute helix with the name of your account5 Type CTRL+o to save then press enter then type CTRL+x to exitnano text editor The syntax is critical - if sudoers is messed upyour OS may not boot The reason this is done is that most of theapplications we wish to use run at root However user accounts donot have root privileges This is overcome by using the sudocommand which periodically requires you to enter a password whichis a pain Editing the sudoers file as shown above removes therequirement to enter a password when sudo is used6 By default there are three icons in the panel like Windows QuickLauch on the taskbar at the top of the desktop Firefox, help andterminal Right click on Terminal and Remove from Panel7 Access Applications-Forensics et IR-Root Terminal in the menuand right click and select Add to PanelImaging ApplicationsI work in an Encase shop so I am going to concentrate on applicationsthat image to EWF format aka e01 files There are currently twoapplications installed that do this - Linen and EWFacquireLinenLinen needs some configuration to run from the shortcutApplications-Forensics et IR-Linen This shortcut I think the properlinux terminology is launcher runs a script called sl in /usr/bin slneeds editing1 Applications-Forensics et IR-Root Terminal or click on RootTerminal in the Panel2 :~# nano /usr/bin/sl3 Use nano to delete the linecp /cdrom/IR/bin/linen /usr/local/bin4 Type CTRL+o to save then press enter then type CTRL+x to exitnano text editorAt this stage Linen does not reside in /usr/local/bin - we need to putan up to date copy there1 On a Windows box where Encase version 6 is installed copy theLinen file from the root Encase folder within Program Files to athumb drive2 On the Helix box copy Linen from the thumb drive to/usr/local/bin as follows:3 Launch root terminal from panel on task bar and mount your thumbdrive by clicking on it's icon on the task bar and selecting Mount4 :~# cp /media/sdc1/linen /usr/local/bin where sdc1 is your thumbdriveLinen should now be launchable via the menu But in true windows styleI created a desktop shortcut by right clicking the Linen menu item andselecting add launcher to desktopEWFacquireEWF Acquire is installed and will run from the root terminal Thisprogram is part of the libewf project The syntax isewfacquire /dev/sdbwhere /dev/sdb is the drive to be imaged Again I created a desktopshortcut by:1 Right clicking on the desktop and selecting Create Launcher2 Change the type to Application in Terminal3 Set the name appropriately4 In the command box type sudo /usr/bin/ewfacquire /dev/sdb5 Click OKIt is probably worth noting that you would not want to launchEWFacquire from the desktop launcher unless you had established thepath of each drive by typing fdisk -l into the root terminalGuymagerGuymager is another imaging tool that utilises Libewf It iscontrolled from a GUI and is a desirable addition to our imagingtools I intend to do a mini review of it along with steps I havecarried out to validate it in a forthcoming blog post It is notinstalled on the Helix CDRom but can be installed to our hard diskinstallation1 Launch a Root Terminal2 :~# nano /etc/apt/sourceslist3 Use arrow keys to scroll to end of file then type debhttp://aptpinguinlu/i386 /4 Type CTRL+o to save then press enter then type CTRL+x to exitnano text editor5 Whist still connected to internet type in root terminal6 :~# apt-get update7 :~# apt-get install guymager smartmontools hdparm libewf-toolsOnce the process is completed guymager can be launched from a rootterminal Again I created a desktop shortcut by:1 Right clicking on the desktop and selecting Create Launcher2 Change the type to Application in Terminal3 Set the name appropriately4 In the command box type sudo /usr/bin/guymager5 Click OKGuymager utilises a configuration file - guymagercfg For my setup Iwanted to make some changes The program advises that changes shouldbe made to localcfg, however I did not have much success with this Iedited guymagercfg with nano:1 Launch a Root Terminal2 :~# nano /etc/guymager/guymagercfgand modify entries to the following3 Language='en'EwfFormat=Encase5EwfCompression=BestEwfSegmentSize=15004 and in the Table LocalDevices area add a new line beneath theline of ------------containing the serial number of the hard disk drive where Helix isinstalledeg '1ATA_Maxtor_6B300S0_B605MV0H'The best way to establish the serial no is probably with Guymageritself5 Many other changes can be made as documented within guymagercfg6 Type CTRL+o to save then press enter then type CTRL+x to exitnano text editorAdeptoAlthough Adepto does not image to EWF files I know some people use itSome changes need to be made to get it to work1 Launch a File Browser with root permissions by launching a rootterminal and typing nautilus2 Use the file browser to navigate to /home/helix helix being thename of the user account I created during the installation routine- if you used another account name navigate to/home/theAccountNameYouUsed 3 Right click or use the edit menu to create a folder then name itAdepto4 Double click Adepto and create a subfolder within Adepto calledLogs5 Right click on Logs and Make Link6 Right click on the resulting Link to Logs and Cut7 Navigate to /usr/local/adepto and paste your link file8 Right click on the existing Logs file and delete9 Rename Link to logs to logsAdepto should work nowSome Networking StuffIn our lab we image to a file server running Microsoft Windows Server2003 When I have used the Helix CDs in the past it was always a painto image to an attached hard drive then transfer the image to the fileserver later I wanted the Helix Imager to image direct to our fileserver and be part of our Windows WorkgroupTo do this:1 via System-Administration-Network configure to connect to yourinternal network2 on the windows file server create a share I called mine Helixand create a user named Helixuser having done this you can applyappropriate security to this user at the Windows end3 Create a mount point to the windows share by:4 Launch a Root Terminal5 :~#mkdir /media/helix6 :~# nano /etc/nsswitchconfmodify add wins prior to dns the following line to readhosts: files mdns4_minimal NOTFOUND=return wins dns mdns4Type CTRL+o to save then press enter then type CTRL+x to exit nanotext editor7 :~# nano /etc/fstab8 Append the line below to the end of the fstab file//server/Helix /media/helix cifsusername=user,password=*,iocharset=utf8,file_mode=0777,dir_mode=07770 0where server is your server name, Helix is the name of yourWindows share, helix is the name of the linux mount point, user isthe name of an account on your Windows server and * is substitutedfor whatever your password is9 Type CTRL+o to save then press enter then type CTRL+x to exitnano text editor10 :~# mount -a11 Configure the way the Helix Imager box is recognised within ourWindows Workgroup12 at the root terminal :~# nano /etc/samba/smbconf13 Within the global settings area modify entries to the followingworkgroup = THENAMEOFYOURWORKGROUPserver string = %hNow that a mount point has been created to your windows sharespecifying /media/helix as the path to image to in Linen, EWFacquireor Guymager will output the image to the Windows File ServerIMAGEhttp://www.secuobs.com/revue/news/103541.shtmlhttp://www.secuobs.com/revue/news/103541.shtml Secuobs.com : 2009-05-30 14:20:32 - Forensics from the sausage factory - From time to time the subject of linking USB flash drives to aparticular PC crops up A week or so ago I saw a post on the Guidanceboards touching on this subject and chipped in with a link to a paperreferencing Harlan Carvey's original research in this area The nub ofthis issue is that many USB flash drives have a unique device serialnumber which is recorded into the registry of Windows boxes that havehosted said flash driveWhen investigating this issue establishing a USB flash drives deviceserial number may be achieved by utilising a utility such as UVCViewIn our lab we use the Tableau T8 USB write blocker to do this Whenchecking out the subject again prior to posting to the thread on theGuidance boards referred to above I discovered that my Mac Book Proalso has a utility that can establish a USB flash drives device serialnumber The utility is an application called USB Prober which isinstalled as part of the XCode developer tools which can be found onthe separate DVD along with the Mac OS disc for those that have aMacTo use USB Prober for this purpose the Mac needs to configured so thatit does not mount the USB flash drive To do this disk arbitrationneeds to be turned off In Leopard in terminal the command is:sudo launchctl unload/System/Library/LaunchDaemons/comapplediskarbitrationdplistIMAGEOnce disk arbitration simply launch USB Prober via spotlightis the quickest way and drill down to the device serial numberReferenceshttp://wwwmacosxforensicscom/Technologies/DiskArbitration/DiskArbitrationhtmlhttp://scissecscisecueduau/conference_proceedings/2007/forensics/23_Luo_Tracing_USB_Device_artefacts_on_Windows_XPpdfhttp://developerapplecom/documentation/MacOSX/Conceptual/OSX_Technology_Overview/Tools/ToolshtmlIMAGEhttp://www.secuobs.com/revue/news/103540.shtmlhttp://www.secuobs.com/revue/news/103540.shtml