Is this how the exploit loads and initiates when surfing. This assumes Joe Bloggs using Windows XP Home(SP2) and surfing with a vulnerable IE6. I go to a Web page - embedded in that page is a container/iframe which may be invisible to the observer and contains a URL which calls up a .WMF file. Good Example of a basic iframe in use:- http://www.codetoad.com/html/frames/iframes.asp Assuming it is not stopped by filtering/blocking this is then cached. Once loaded client side it is designed to take advantage of Windows default behaviour and be opened either by the Microsoft Picture & Fax viewer, or an alternative viewer that makes use of the driver shimgvw.dll. The point of all this being to have these programs/drivers in active memory space in order to take advantage of a buffer overflow weakness ? In this case, to place in the vulnerable memory space a pointer to and/or a newly embedded instruction which is also placed in this exploitable memory space. The point being to instruct a download of whatever dodgy.exe is pointed to ? Buffer overflows explained in easy terms:- http://www.watchguard.com/infocenter/editorial/135136.asp If so - is it the driver shimgvw.dll that is directly vulnerable to the exploit or is the driver simply an avenue to the Escape() function in gdi32.dll. This being the real weakness that creates the possibility for the exploit ? This being the reason that the unofficial patch preventing the escape function is more valuable than un-registering the shimgvw.dll, which could potentially be re-registered by malware ? Or have I missed the point totally ? I was gonna post this privately to a member I trust for his comment - but I figure I'm so new to this and currently working on such a basic level that your responses may be useful to other people on the same level. Even if all I have said is wrong - I'm assuming now this framework has been provided - it can be corrected in a way that anyone can understand - even me.