Linking Win7 Thumbn...
 
Notifications
Clear all

Linking Win7 Thumbnail Cache to Windows.edb

17 Posts
8 Users
0 Likes
2,462 Views
(@twjolson)
Posts: 417
Honorable Member
Topic starter
 

Based on the article on forensicwiki, it seems that the Thumbcache ID of the files in the Thumbcache is also found in the Windows Index.

I have a list of thumbcache filenames (1f7e4be6e7e95dcc.jpg, for example), I eliminated the extensions, and used grep to try and find the filename in the database (the SystemIndex_0A table specifically) after I exported it via esedexport.

Twice I have tried this on two cases, and I haven't gotten a single hit.

Am I doing something wrong, or am I in error to think you can use the Thumbcache ID to find out more information about the original file?

 
Posted : 28/01/2012 2:04 am
(@xennith)
Posts: 177
Estimable Member
 

The number that esedbexport pulls out as the thumb identifier is converted to little endian and stored in unicode in the thumbscache_256 file record header, its the last 32 bytes before the start of the jpg.

So if you're looking for "1f7e4be6e7e95dcc" you want to do a unicode search for "cc5de9e7e64b7e1f"

 
Posted : 28/01/2012 3:41 pm
(@bohdi)
Posts: 11
Active Member
 

I have been looking for the same type of information around half a year ago, and what I found really difficult was the lack of written information about this.

If anyone has links to documented information I would be very happy to read them )

 
Posted : 28/01/2012 7:16 pm
(@xennith)
Posts: 177
Estimable Member
 

What there is out there isnt exactly complete, but libesedb is pretty good. I've been working on this for a few days and I think the thumbscache_XXX files can be broken down into records as follows (on vista at least)

CMMM - Header
4 Bytes - Unknown data
8 Bytes - Unique identifier linking thumbnail entry to thumbscache_idx
8 Bytes - Unicode encoded file extension
8 Bytes - Some kind of coded value, flags perhaps?
8 Bytes - Length of thumbnail data
8 Bytes - Checksum of thumbnail data
8 Bytes - Checksum of header
32 Bytes - Unicode encoded "filename" attribute, endian reversed compared to the corresponding entry in the windows.edb file

Image data of varying length

 
Posted : 28/01/2012 8:06 pm
(@paulandrewsfca)
Posts: 10
Active Member
 

Hi Xennith

The 4 bytes of unknown data at the beginning is a 32 bit integer giving the size of the whole record. The 8 bytes of 'Some kind of coded value, flags perhaps?' is a 32bit integer giving the length of the UID, followed by 4 bytes of 0x00 (unless it's a thumbcache_96.db, where the thumbnails are stored as Bitmaps, when it will be 0x02000000 - and you then get two bytes of padding between the UID in Unicode and the start of the Bitmap).

The Windows 7 (and Windows 8 ) thumbache records are slightly different, but follow broadly the same structure.

Regards
Paul

 
Posted : 30/01/2012 2:07 pm
(@paulandrewsfca)
Posts: 10
Active Member
 

And further to the OP's question about finding corresponding entries for the thumbnails in the Windows.edb; if the original image is no longer present (either deleted, or came from an external medium etc) then you will be very lucky to find an entry relating to it in the Windows.edb at all.
You may luck out and find an entry in a Shadow Volume version of the Windows.edb (if such a thing exists).

This is why EnCase (for Vista at least) can only identify the original filename for a cached thumbnail where the original image still exists in the volume.

Regards
Paul

 
Posted : 30/01/2012 2:18 pm
(@xennith)
Posts: 177
Estimable Member
 

Thanks Paul, its all starting to come together now.

Just writing a little program to attempt to link the thumbcache images to the windows.edb file, I'll have a bit of a test and see what I find. Its discouraging that you think its unlikely to do much for deleted images but it does seem worth doing.

 
Posted : 30/01/2012 5:26 pm
(@paulandrewsfca)
Posts: 10
Active Member
 

Hi Xennith

It's definitely worth writing the program. I never had any luck with getting details in relation to deleted / not present images, but as with everything, your mileage may vary!

One possibilty would be finding Volume Shadow Copy versions of the windows.edb file, and then searching those? I can't recall whether or not the windows.edb file is part of the Volume Shadow Copy process though…

Regards
Paul

 
Posted : 30/01/2012 5:47 pm
(@twjolson)
Posts: 417
Honorable Member
Topic starter
 

Thank you very much for the information.

Trying to reverse the ThumbcacheID name, I had no luck. But then, almost every file of interest was deleted.

Searching for filenames also gave me nothing.

Just general browsing, I am not seeing much information of interest anyways.

That said, I really find Windows.edb interesting, and I am flabbergasted the forensics community hasn't given it more attention. This is my main focus of research, once I get some free time.

 
Posted : 30/01/2012 7:33 pm
finbarr
(@finbarr)
Posts: 26
Eminent Member
 

The Windows.edb file is expressly excluded from Volume Shadow Copy, so you won't find anything there.

Additionally, much of the contents of the windows.edb file are obfuscated, so simple searches will fail. The libesedb project from Joachim Metz is a brilliant piece of reverse engineering work and this will allow you to defeat the obfuscation and obtain the clear-text version of the original data.

The Windows Desktop Search (WDS) system works very closely with NTFS meaning that within a very short time period, any file deletions in NTFS will be mirrored in the WDS database - so the likelihood of determining the original file provenance of a recovered thumbnail from cache belonging to a deleted photograph is quite low, I'm sad to say. cry

It is an interesting area and it does contain some real gems - especially with respect to indexed material present on removable devices where the original media is not available.

Kind regards,

John Douglas
LangfordParc.

 
Posted : 31/01/2012 2:40 am
Page 1 / 2
Share: