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.