{"id":777,"date":"2009-01-28T22:46:01","date_gmt":"2009-01-28T20:46:01","guid":{"rendered":"https:\/\/alax.info\/blog\/?p=777"},"modified":"2013-07-08T22:44:00","modified_gmt":"2013-07-08T20:44:00","slug":"directshow-filtergraphspy","status":"publish","type":"post","link":"https:\/\/alax.info\/blog\/777","title":{"rendered":"DirectShow Filter Graph Spy"},"content":{"rendered":"

Inspired by a post on DirectShow Development Forum<\/a>, it is sometimes useful to find out how certain application is using DirectShow to capture live video and\/or audio, or play certain file etc. Filter graph topology, details about media types on the pins, used interfaces and call order. There is quite an easy step for the developer to spy over running filter graphs system wide by connecting Component Object Model<\/a> (COM) “Treat As” feature with filter graph remoting through Running Object Table<\/a> and connecting to remote process graphs using GraphEdit<\/a> utility. Who could imagine Windows Media Player to build such a filter graph for a video and audio Windows Media file? SRS Wow DMO, equalizer, analyzer and stuff? \"\"<\/a> There are many tricks to catch the created filter graph but the most legit is the mentioned above “Treat As” feature to emulate certain COM class identifier (CLSID) through another coclass. COM API offers<\/p>\n

CoTreatAsClass<\/a> and CoGetTreatAsClass<\/a> functions to manage the emulation. To emulate DirectShow’s CLSID_FilterGraph<\/a> through my CSpy class, I am adding the following code to the default COM registration process for the utility DLL:<\/p>\n

static HRESULT WINAPI UpdateRegistry(BOOL bRegister) throw()\n{\n    _Z2(atlTraceRegistrar, 2, _T(\"bRegister %d\\n\"), bRegister);\n    _ATLTRY\n    {\n        CLSID TreatAsClassIdentifier;\n        HRESULT nCoGetTreatAsClassResult = CoGetTreatAsClass(CLSID_FilterGraph, &TreatAsClassIdentifier);\n        __C(nCoGetTreatAsClassResult);\n        __D(!bRegister || nCoGetTreatAsClassResult != S_OK || TreatAsClassIdentifier == GetObjectCLSID(), E_UNNAMED);\n        if(!bRegister && nCoGetTreatAsClassResult == S_OK)\n            __C(CoTreatAsClass(CLSID_FilterGraph, CLSID_NULL));\n        _A(_pAtlModule);\n        UpdateRegistryFromResource<CSpy>(bRegister);\n        if(bRegister)\n            __C(CoTreatAsClass(CLSID_FilterGraph, GetObjectCLSID()));\n    }\n    _ATLCATCH(Exception)\n    {\n        _C(Exception);\n    }\n    return S_OK;\n}\n<\/code><\/pre>\n
The idea is that the emulation is enabled in case it was not enabled before or it was already enabled through our coclass. Every time an application cocreates an instance of Filter Graph Manager (FGM), CSpy class will be created instead. Still as we have no plans to reinvent one of the most important DirectShow objects, we have to embed the original FGM insde to forward the calls to. The proper place in the ATL C++ code is FinalConstruct and what we actually do there is instantiating an aggregated FGM from the original in-process server. The safest would be to query registry for the original host, but we know it’s hosted by quartz.dll and it seems to be safe to hardcode:<\/p>\n
HINSTANCE hModule = CoLoadLibrary(_T(\"quartz.dll\"), TRUE);\n_ATLTRY\n{\n    typedef HRESULT (WINAPI *DLLGETCLASSOBJECT)(REFCLSID, REFIID, VOID**);\n    DLLGETCLASSOBJECT DllGetClassObject = (DLLGETCLASSOBJECT) GetProcAddress(hModule, \"DllGetClassObject\");\n    __E(DllGetClassObject);\n    CComPtr<IClassFactory> pClassFactory;\n    __C(DllGetClassObject(CLSID_FilterGraph, __uuidof(IClassFactory), (VOID**) &pClassFactory));\n    _A(pClassFactory);\n    CComPtr<IUnknown> pUnknown;\n    __C(pClassFactory->CreateInstance(GetControllingUnknown(), __uuidof(IUnknown), (VOID**) &pUnknown));\n    CComQIPtr<IFilterGraph2> pFilterGraph2 = pUnknown;\n    __D(pFilterGraph2, E_NOINTERFACE);\n<\/code><\/pre>\n
What is remained at the point is to implement IFilterGraph2 (along with inherited IGraphBuilder and IFilterGraph) and forward all incoming calls to the inner aggregated object. It would also be helpful to trace calls to a log file C:\\FilterGraphSpy.log:<\/p>\n
2009-01-28 22:07:51    4456    5656    dllmain.h(29): CFilterGraphSpyModule::CFilterGraphSpyModule: this 0x01cd327c\n2009-01-28 22:07:51 4456    5656    Spy.h(75): CSpy::CSpy: this 0x01ce297c\n2009-01-28 22:07:51 4456    5656    Spy.h(132): CSpy::AddFilter: pszName \"C:\\Documents and Settings\\John Doe\\Desktop\\Melissa Cherry Interview.wmv\"\n2009-01-28 22:07:51 4456    5656    Spy.h(142): CSpy::EnumFilters: ...\n2009-01-28 22:07:51 4456    5656    Spy.h(132): CSpy::AddFilter: pszName \"ffdshow Audio Decoder\"\n2009-01-28 22:07:51 4456    5656    Spy.h(152): CSpy::ConnectDirect: ...\n2009-01-28 22:07:51 4456    5656    Spy.h(137): CSpy::RemoveFilter: ...\n2009-01-28 22:07:51 4456    5656    Spy.h(132): CSpy::AddFilter: pszName \"WMAudio Decoder DMO\"\n2009-01-28 22:07:51 4456    5656    Spy.h(152): CSpy::ConnectDirect: ...\n2009-01-28 22:07:51 4456    5656    Spy.h(142): CSpy::EnumFilters: ...<\/pre>\n
And additionally, the filter graph is immediately published on the ROT and is accessible with<\/p>\n
GraphEdit<\/a>. Feel free to spy over graphs system wide. A partial Visual C++ .NET 2008 source code is available from SVN<\/a> (outdated!), release binary included<\/a>.<\/p>\n
\n  To install Filter Graph Spy: <\/p>\n