Windows Live Messenger – MessengerCache folder

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\<user_name>\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.

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.

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.

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.

Old Servers never die – unfortunately

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 1.5 megabytes per second (MB/s) which equates to 5.4 Gigabytes per hour.  There were not going to be enough hours in this weekend to image both arrays on the server. 

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 1.46 gigabytes a minute or nearly 88 gigabytes an hour using gigabit network interface cards.  In testing I have achieved 39 gigabytes an hour using 10/100 NICS.

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 192.168.0.100 on onsite laptop and ifconfig eth0 192.168.0.101 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 192.168.0.100 or ping –c 5 192.168.0.101 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 192.168.0.100 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 192.168.0.100 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 (39.6 GB/h) can be expected. Compression and block size does affect imaging speed and if you have time it may be worth fine-tuning these settings. The settings shown in this post are probably a good starting point. To fine-tune, run the imaging process with the settings in this post. After 5 minutes or so if you are getting poor speeds stop the process and try adjusting the compression size on the onsite laptop (i.e. change from none to fast). Sometimes either doubling or halving the block size on both source and receiver machines can make a difference also.

Adobe Bridge CS3 and some MySQL stuff

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_Nodes.MYD  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_Nodes.MYD was

~\Library\Caches\Adobe\Bridge CS3\Cache\data\BridgeStore\FileSystem_Nodes.MYD

and within the same folder were two other files of note FileSystem_Nodes.MYI and FileSystem_Nodes.frm.  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.

Figure 1

I was tasked with ascertaining more information about each picture located within the FileSystem_Nodes.MYD file.  So in order to do this 

• I installed MySQL version 5.5.20 on a test Apple iMac running Snow Leopard (I would expect that a MS Windows version would work just as well).  

  
  

• 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-5.5.20-osx10.6-x86\data on my Mac and restarted the MySQL database server.

  
  

• Using MySQL Administrator I could view some information relating to the BridgeStore database

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

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

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_Nodes.myd file using this method.

References

http://http://en.wikipedia.org/wiki/MyISAM

http://dev.mysql.com/doc/refman/5.5/en/myisam-storage-engine.html

Missing in action

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 NTUSER.dat registry file and is used to record how many days history Internet Explorer keeps for the particular user.  As many of us know the default is 20 days.  In a recent case the value of this key was pertinent and when I went to examine it on two separate boxes I found it was missing.

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.

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.