[Mr Snrub]

Okay, you did the hard work
The hook points to the module which is always missing when explorer calls into the msgina function, which in turn leads to the crash - the module is therefore unloading (without a trace) but also without unhooking itself first - bad.

With the breakpoint on the attempt to write to the IsDebuggerPresent, rather than use "g" to continue it is simpler to look at the threads to see which was doing the write:

The 1-byte write operation we were watching for has taken place, we replaced 0x64 with 0xe9:

Quote

0:024> !chkimg -d kernel32
7c813123 - kernel32!IsDebuggerPresent
[ 64:e9 ]
1 error : kernel32 (7c813123)

Looking through the list of threads it was easy to spot the one which has the module you already hinted at (24):

Quote

0:024> kvL 50
ChildEBP RetAddr Args to Child
0490e590 04a7f2ac 7c813123 04a4c530 7c813123 Mpeg2DecFilter!DllGetClassObject+0x21235
0490e5a4 04a7f1cd 7c813123 04a4c530 00000006 Mpeg2DecFilter!DllGetClassObject+0x211dc
0490e60c 04a7f452 7c813123 04a4c510 04a4c530 Mpeg2DecFilter!DllGetClassObject+0x210fd
0490e628 04a7f364 04a4c510 04a4c530 00000000 Mpeg2DecFilter!DllGetClassObject+0x21382
0490e640 04a51fa9 04a4c510 04a4c530 04a613a5 Mpeg2DecFilter!DllGetClassObject+0x21294
0490e660 04a6e30b 04a40000 00000000 00000000 Mpeg2DecFilter!DllUnregisterServer+0x5ab9
0490e6a0 04a6e3b2 04a40000 7c90118a 04a40000 Mpeg2DecFilter!DllGetClassObject+0x1023b
0490e6c8 7c91c4da 04a6e395 04a40000 00000001 Mpeg2DecFilter!DllGetClassObject+0x102e2
0490e7d0 7c916351 00000000 c0150008 00000000 ntdll!LdrpRunInitializeRoutines+0x344
0490ea7c 7c9164b3 00000000 00105350 0490ed70 ntdll!LdrpLoadDll+0x3e5
0490ed24 7c801bbd 00105350 0490ed70 0490ed50 ntdll!LdrLoadDll+0x230
0490ed8c 77512485 0490ee08 00000000 00000008 kernel32!LoadLibraryExW+0x18e
0490edb0 775123a1 0490ee08 0490edd4 0490edd8 ole32!CClassCache::CDllPathEntry::LoadDll+0x6c
0490ede0 77511824 0490ee08 0490f0e4 0490ee00 ole32!CClassCache::CDllPathEntry::Create_rl+0x37
0490f02c 77511747 00000001 0490f0e4 0490f05c ole32!CClassCache::CClassEntry::CreateDllClassEntry_rl+0xd6
0490f074 775116a5 00000001 0397da30 0490f09c ole32!CClassCache::GetClassObjectActivator+0x195
0490f0a0 7751120f 0490f0e4 00000000 0490f6d8 ole32!CClassCache::GetClassObject+0x23
0490f11c 775110b3 77607150 00000000 0490f6d8 ole32!CServerContextActivator::CreateInstance+0x106
0490f15c 77511302 0490f6d8 00000000 0490fc24 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
0490f1b0 77511279 77607154 00000000 0490f6d8 ole32!CApartmentActivator::CreateInstance+0x110
0490f1d0 775120c8 77607154 00000001 00000000 ole32!CProcessActivator::CCICallback+0x6d
0490f1f0 7751207f 7760714c 0490f534 00000000 ole32!CProcessActivator::AttemptActivation+0x2c
0490f228 77511363 7760714c 0490f534 00000000 ole32!CProcessActivator::ActivateByContext+0x42
0490f250 775110b3 7760714c 00000000 0490f6d8 ole32!CProcessActivator::CreateInstance+0x49
0490f290 7751104e 0490f6d8 00000000 0490fc24 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
0490f4e0 775110b3 77607114 00000000 0490f6d8 ole32!CClientContextActivator::CreateInstance+0x8f
0490f520 77510ef8 0490f6d8 00000000 0490fc24 ole32!ActivationPropertiesIn::DelegateCreateInstance+0xf7
0490fcd0 77500575 041920f8 00000000 00000401 ole32!ICoCreateInstanceEx+0x3c9
0490fcf8 77500544 041920f8 00000000 00000401 ole32!CComActivator::DoCreateInstance+0x28
0490fd1c 775005b2 041920f8 00000000 00000401 ole32!CoCreateInstanceEx+0x1e
0490fd4c 75f45c70 041920f8 00000000 00000401 ole32!CoCreateInstance+0x37
0490fe00 7486bf25 041920d8 0218d3e8 00000000 devenum!CDeviceMoniker::BindToObject+0x188
0490fe20 748494af 0158f590 0158f884 7e4188a6 quartz!CFilterGraph::OnCreateFilter+0x31
0490fe58 74827810 0045045a 0000040a 0158f590 quartz!CFGControl::CGraphWindow::OnReceiveMessage+0x2c8
0490fe7c 7e418734 0045045a 0000040a 0158f590 quartz!WndProc+0x96
0490fea8 7e418816 748277d2 0045045a 0000040a user32!InternalCallWinProc+0x28
0490ff10 7e4189cd 00000000 748277d2 0045045a user32!UserCallWinProcCheckWow+0x150
0490ff70 7e418a10 0490ff98 00000000 0490ffb4 user32!DispatchMessageWorker+0x306
0490ff80 7486eb0a 0490ff98 7c912d58 00000000 user32!DispatchMessageW+0xf
0490ffb4 7c80b713 00000000 7c912d58 00000000 quartz!ObjectThread+0x95
0490ffec 00000000 7486ea75 000006f8 00000000 kernel32!BaseThreadStart+0x37

Looking at the second frame's return address we can see what address it started at in frame 1:

Quote

0:024> u Mpeg2DecFilter!DllGetClassObject+0x211dc-5
Mpeg2DecFilter!DllGetClassObject+0x211d7:
04a7f2a7 e844000000 call Mpeg2DecFilter!DllGetClassObject+0x21220 (04a7f2f0)
04a7f2ac 83c40c add esp,0Ch

Now we can unassemble from this function entry point and see what it does:

Quote

0:024> u Mpeg2DecFilter!DllGetClassObject+0x21220 Mpeg2DecFilter!DllGetClassObject+0x21235
Mpeg2DecFilter!DllGetClassObject+0x21220:
04a7f2f0 55 push ebp
04a7f2f1 8bec mov ebp,esp
04a7f2f3 837d1000 cmp dword ptr [ebp+10h],0
04a7f2f7 7506 jne Mpeg2DecFilter!DllGetClassObject+0x2122f (04a7f2ff)
04a7f2f9 8b4508 mov eax,dword ptr [ebp+8]
04a7f2fc 894510 mov dword ptr [ebp+10h],eax
04a7f2ff 8b4d08 mov ecx,dword ptr [ebp+8]
04a7f302 c601e9 mov byte ptr [ecx],0E9h

There is the "put byte value 0xe9 into address pointed to by register ECX" instruction, where ECX was set up to point to the IsDebuggerPresent function.

The entire function just seems to replace a single byte at a time, so must be called 6 times to place the hook - I assume this is to avoid detection by containing the offset as a string of bytes, this is all of it:

Quote

0:024> u Mpeg2DecFilter!DllGetClassObject+0x21220 04a7f32c
Mpeg2DecFilter!DllGetClassObject+0x21220:
04a7f2f0 55 push ebp
04a7f2f1 8bec mov ebp,esp
04a7f2f3 837d1000 cmp dword ptr [ebp+10h],0
04a7f2f7 7506 jne Mpeg2DecFilter!DllGetClassObject+0x2122f (04a7f2ff)
04a7f2f9 8b4508 mov eax,dword ptr [ebp+8]
04a7f2fc 894510 mov dword ptr [ebp+10h],eax
04a7f2ff 8b4d08 mov ecx,dword ptr [ebp+8]
04a7f302 c601e9 mov byte ptr [ecx],0E9h
04a7f305 8b5508 mov edx,dword ptr [ebp+8]
04a7f308 83c201 add edx,1
04a7f30b 895508 mov dword ptr [ebp+8],edx
04a7f30e 8b4510 mov eax,dword ptr [ebp+10h]
04a7f311 83c005 add eax,5
04a7f314 8b4d0c mov ecx,dword ptr [ebp+0Ch]
04a7f317 2bc8 sub ecx,eax
04a7f319 8b5508 mov edx,dword ptr [ebp+8]
04a7f31c 890a mov dword ptr [edx],ecx
04a7f31e 8b4508 mov eax,dword ptr [ebp+8]
04a7f321 83c004 add eax,4
04a7f324 894508 mov dword ptr [ebp+8],eax
04a7f327 8b4508 mov eax,dword ptr [ebp+8]
04a7f32a 5d pop ebp
04a7f32b c3 ret

So this isn't by mistake, the module is most definitely doing a deliberate hook in a manner that is trying to avoid detection, for what reason I couldn't say.
Take a look at the top few frames of the call stack again:

Quote

0490e590 04a7f2ac 7c813123 04a4c530 7c813123 Mpeg2DecFilter!DllGetClassObject+0x21235
0490e5a4 04a7f1cd 7c813123 04a4c530 00000006 Mpeg2DecFilter!DllGetClassObject+0x211dc
0490e60c 04a7f452 7c813123 04a4c510 04a4c530 Mpeg2DecFilter!DllGetClassObject+0x210fd

0:024> ln 7c813123
Exact matches:
kernel32!IsDebuggerPresent (void)

0:024> ln 04a4c530
(04a4c4f0) Mpeg2DecFilter!DllUnregisterServer+0x40 | (04a5e050) Mpeg2DecFilter!DllCanUnloadNow

Quote

0:024> lmvm Mpeg2DecFilter
start end module name
04a40000 04ab1000 Mpeg2DecFilter (export symbols) Mpeg2DecFilter.ax
Loaded symbol image file: Mpeg2DecFilter.ax
Image path: C:\Program Files\Combined Community Codec Pack\Filters\Mpeg2DecFilter.ax
Image name: Mpeg2DecFilter.ax
Timestamp: Thu May 17 11:37:09 2007 (464C2245)
CheckSum: 00076973
ImageSize: 00071000
File version: 1.0.0.3
Product version: 1.0.0.3
File flags: 0 (Mask 17)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Gabest
ProductName: Mpeg2Dec Filter
InternalName: Mpeg2Dec Filter
OriginalFilename: Mpeg2DecFilter.ax
ProductVersion: 1, 0, 0, 3
FileVersion: 1, 0, 0, 3
FileDescription: MPEG-1/2 Decoder Filter for DirectShow
LegalCopyright: Copyright © 2003-2006 Gabest
Comments: http://gabest.org/

When explorer.exe does not crash, this module is still loaded and so the IsDebuggerPresent hook can jump into this module without causing an exception - if it has been unloaded then it goes boom, and that's the only reason we spot this dodgy behaviour.

[zan2828]

Impressive. I think I can manage from here.

I am very grateful for all your help, and I have learned a lot as well from your methodical and detailed posts. If you don't mind me asking, do you do this sort of work for a living, or is it simply a hobby?

This post has been edited by zan2828: 26 June 2008 - 05:10 AM

[Mr Snrub]

You are welcome, and the answer is "both"
Though I'm not half as good as some of the guys that work here.

[zan2828]

How would I go about setting a breakpoint so that the debugging breaks when the module unloads?

[Mr Snrub]

Attach to your process using Windbg.
Click Debug / Event Filters.
Select the 6th entry in the list "Unload module", click the radio button "Enabled".
Click Close, then enter "g" to let the debuggee resume.
Debugger will now break in whenever a module unloads.