아래와 같은 질문이 있었습니다.
IWebBrowser2를 통해 웹컨트롤을 만들 때 특정 ActiveX만 허용하고 차단하는 방법이 있을까요? ; http://social.msdn.microsoft.com/Forums/ko-KR/visualcplusko/thread/82468d1f-fd2b-45d0-8b0e-4bc75af1d06b
질문자의 말대로, 웹 브라우저를 사용자 정의해서 DLCTL_NO_DLACTIVEXCTLS | DLCTL_NO_RUNACTIVEXCTLS 플래그를 설정해주면 IE Web Browser 컨트롤에서 활성화되는 모든 ActiveX를 비활성화 시킬수 있습니다.
하지만, "Flash" 만 허용하고 - 즉, 특정 ActiveX 만 허용하고 다른 컨트롤을 차단하는 기능은 없습니다.
그래도... 어떻게 다른 방법으로 해결할 수 있지 않을까요? 그래서 처음 이 문제를 봤을 때, Win32 API 후킹을 하면 되지 않을까?... 하는 생각을 하게 되었습니다. 그렇습니다. ^^ 지난 번 글은 바로 위의 질문 때문에 씌여진 것입니다. ^^
Win32 API 후킹 - Trampoline API Hooking ; http://www.sysnet.pe.kr/2/0/1231
뜻하지 않게 "Trampoline API Hooking" 도 익힐 수 있었던 좋은 과제였지요. ^^
그런데, 문제는 어떤 API 를 가로채야 하는 것인지에 대해서부터 시행착오를 하게 되었습니다. 저는 그냥 단순히 CoCreateInstance(Ex) 일줄 알았는데 IE 안에서 ActiveX 가 활성화될 때 그쪽 API 들은 전혀 불리지 않았습니다. 다행히 그 다음 시도해 본 API 로 성공을 했는데요... 바로 CoGetClassObject 였습니다.
재미있는 것은 CoGetClassObject 로 넘어오는 CLSID 에는 UI 용 ActiveX 이외에도 다음과 같은 것들이 있었습니다.
- {CLSID_HTML Document}
- {CLSID_Microsoft HTML About Pluggable Protocol}
- {CLSID_Security Manager}
가로채야 할 API 는 확인되었고... 이제 진짜 문제가 남았는데요. 과연...? 어떤 기준으로 활성화될 ActiveX를 필터링해야 하느냐입니다.
아쉽지만, 이에 대한 정답은 없습니다. 일단, 이렇게 Hooking 쪽으로 넘어온 이상 이런 류의 문제는 꼭 발생한다고 봐야 합니다. 그래도 문제를 해결해야 하기 때문에, 이런 경우 최대한 적당한(?) 수준의 정책을 찾아내야 하는데요.
테스트를 해보니, CoGetClassObject 로 넘어온다던 위의 3가지 CLSID 는 모두 mshtml.dll 에서 활성화되는 것들이었습니다. 아하... 그렇다면 CLSID 로 레지스트리를 살펴봐서 InProcServer32 의 값에 명시된 파일 경로 중에서 mshtml.dll 은 무조건 활성화시켜야겠고. 그 외의 것들 중에서는 Flash 의 CLSID 에 해당하는 {D27CDB6E-AE6D-11cf-96B8-444553540000} 값을 제외하고는 전부 비활성화 시키면 된다는 이야기입니다.
대충 다음과 같이 가로채기 함수가 구현될 수 있습니다.
HRESULT WINAPI NeoCoGetClassObject(REFCLSID rclsid, DWORD dwClsContext, COSERVERINFO *pServerInfo, REFIID riid, LPVOID *ppv) { if (CanBeActivated(rclsid) == FALSE) { return REGDB_E_CLASSNOTREG; } return TrampolineCoGetClassObject(rclsid, dwClsContext, pServerInfo, riid, ppv); } BOOL CanBeActivated(REFCLSID rclsid) { wchar_t *chBuf = NULL; StringFromCLSID(rclsid, &chBuf); wchar_t regPath[4096] = { 0 }; wsprintf(regPath, L"CLSID\\%s\\InprocServer32", chBuf); CoTaskMemFree(chBuf); DWORD dwType = REG_SZ; DWORD cbData = MAX_PATH; wchar_t filePath[MAX_PATH] = { 0 }; if (RegGetValue(HKEY_CLASSES_ROOT, regPath, NULL, RRF_RT_REG_SZ, NULL, filePath, &cbData) == ERROR_SUCCESS) { wchar_t mshtmlFileName[MAX_PATH]; _wsplitpath(filePath, NULL, NULL, mshtmlFileName, NULL); if (wcscmp(mshtmlFileName, L"mshtml") != 0) { CLSID flashClsid = CLSID_NULL; CLSIDFromString(L"{D27CDB6E-AE6D-11cf-96B8-444553540000}", &flashClsid); // Internet Explorer 에서 활성화되는 외부 ActiveX 컨트롤임 if (IsEqualCLSID(rclsid, flashClsid) != TRUE) { return FALSE; } } } return TRUE; }
구현은 모두 끝났고... API 후킹이 일종의 편법이기 때문에 이제 확실한 테스트를 해봐야 합니다. ^^
우선, Flash 를 담고 있는 naver 메인 화면을 방문해 보았습니다. 보시는 것처럼 정상적으로 Flash 영역이 활성화되었습니다.

그 다음, 다른 ActiveX 컨트롤들이 정상적(?)으로 비활성화되는지 확인을 해야 하는데요. Windows Media Player 를 담고 있는 제 웹 페이지를 방문해 보았습니다.

확실히 하기 위해, 이번에는 Silverlight 을 담고 있는 웹 페이지를 방문해 본 결과입니다.

어느 정도... 목적 달성은 한 것 같죠? ^^
아직 한가지 남았습니다. 이번엔 Release 모드로 프로젝트를 빌드하고 실행을 해봤는데... 오호 이게 왠일입니까? Navigate 버튼을 누르자마자 비정상 종료하는 현상이 발생했습니다.
몇가지 테스트를 해보니, TrampolineCoGetClassObject 함수의 내용이 전혀 치환되지 않고 그대로임이 밝혀졌습니다. 이런! 난감하군요... Release 빌드라서 디버깅을 해도 변수값이 제대로 안보이니 printf 식의 테스트를 해야하나 싶었는데... 여기서 ^^; 한가지 타협을 하는 것이 좋겠다는 생각이 들었습니다.
어차피... 가로채기 C/C++ DLL 에 국한된 문제이니, 차라리 그에 한해서 코드 최적화를 포기하자는 것입니다. 그래서, 해당 DLL 프로젝트의 코드 최적화 옵션을 끄고,

다시 빌드하고 테스트를 했는데, 다행히 정상적으로 실행이 되었습니다.
마지막으로, 한번 더 테스트는 확실히 해야 합니다. 제 경우에 위의 응용 프로그램을 다시 별도로 설치해 둔 4대의 VM 에서 테스트 해보았습니다.
- Windows Server 2003 x86
- Windows Server 2003 x64
- Windows Server 2008 (x86)
- Windows Server 2008 R2
(Trampoline API 후킹이 아직 x64를 지원하지 않으므로) 32비트로 빌드한 프로그램을 위의 4가지 VM 환경에 배포해서 Debug/Release 모두 정상적으로 실행이 되는 것을 확인했습니다.
하지만... 그래도 여전히 끝난 것은 아닙니다. API Hooking 에 들어선 이상, 늘 테스트는 다양한 환경에서 주의깊게 해주어야 합니다. 위에서는 IE 8/9 를 기준으로 수행했지만, 배포 목적에 따라서 IE 6/7 까지도 해봐야 하고 앞으로 나올 IE 10 도 무시할 수는 없습니다. ^^
어쨌든 위의 프로그램을 첨부했으니, 여러분들도 테스트에 동참해 주시길 바랍니다. ^^