基于ie内核，浏览器自带flash插件「建议收藏」

e内核自带flash方案要比webkit复杂

Ie的flash插件是个ocx，也是com组件。

Windows Com组件的加载过程如下：

1、 通过组件的DllRegisterServer注册com组件，会在注册表生成com组件的路径，guid，progid，threadtype等等

2、 Client通过guid查找到注册表中com组件的地址，loadlibrary加载这个组件，调用com组件的DllGetClassObject接口，此接口返回工厂类IClassFactory接口指针

3、 client通过IClassFactory接口，调用其createInstance接口或者QueryInterface接口可以获取到真正的com应用接口

采用com库函数CoCreateInstance，CoGetClassObject或者CoGetClassObjecFromUrl直接实现了上述过程

第一阶段：

由于ie内核的封闭性，所以ie内核自带flash方案一开始就确定了hookCoCreateInstance，CoGetClassObject、CoGetClassObjecFromUrl，修改ie内核加载flash组件的过程，让ie内核加载我们自带的flash组件

通过调试，发现ie内核是通过CoGetClassObject来加载flash ocx的，不调用CoCreateInstance，所以我们只hook了CoGetClassObject、CoGetClassObjecFromUrl。在hook CoGetClassObject，让ie内核加载了我们的flash ocx，按道理是可以在浏览器上正常显示flash插件了，但是事物的发展通常都是螺旋性的，虽然浏览器拿到了flash的IClassFactory，但是还是没显示成功

第二阶段：

无奈之下只能分析其他浏览器，

在windbg中输入

bp ole32!CoGetClassObject

bp Kernel32！LoadLibraryEx

该浏览器也hook了CoGetClassObject函数，通过ida分析和windbg动态调试，该浏览器的方案是和我们一致的，但是他可以，为什么我们不可以呢

通过processexplorer观察发现，该浏览器进程内包含了两个flash的ocx，通常一个进程加载同一个dll在进程空间只会有一个，但是为什么该浏览器有两个呢，通过仔细发现，这里面有个dll是mapping的data，这个可以通过LoadLibraryEx，最后一个参数传递LOAD_LIBRARY_AS_DATAFILE或者LOAD_LIBRARY_AS_IMAGE_RESOURCE来实现，这样就把dll或者exe通过资源的方式mapping到进程空间，段的属性也是变成”只读”而不是”执行”

通过这个发现，得到了新的思路，就是要把我们的flash也要再加载一次，通过data的方式，于是通过windbg在该浏览器的LoadLibraryEx，CreateFileMapping等处设置断点，想通过这些函数的输入参数来发现点什么，但是结果没发现该浏览器直接LoadLibraryEx（LOAD_LIBRARY_AS_DATAFILE）或者CreateFileMapping

第三阶段：

CreateFileMapping，在做文件映射mapping的时候，他的第一个参数是HANDLE hFile,，如果要用到handle，必定要先CreateFile。于是在我们的浏览器内hook了CreateFile，发现flash插件果然会来调用createfile来加载flash ocx的资源，这时候我们如果修改这个路径，让他调用我们自带的flash ocx，这样是可以了，我们浏览器可以通过我们自带的flash播放了。但是createfile调用比较频繁，hook这个函数在性能上不划算

再想想com的原理，com要找到自己的dll肯定要去注册表找，在看下vc下调试的堆栈，在调用createfile前，flash会先调用oleaut32的接口

通过研究HRESULT LoadRegTypeLib(

REFGUID rguid,

unsigned short wVerMajor,

unsigned short wVerMinor,

LCID lcid,

ITypeLib FAR* FAR *pptlib

);

HRESULT LoadTypeLib(

const OLECHAR FAR *szFile,

ITypeLib FAR* FAR *pptlib

);

The function LoadRegTypeLib defers to LoadTypeLib to load the file.

我们得出了结论flash内部会调用LoadRegTypeLib，这个函数会去注册表通过guid找到flash的ocx路径，然后通过LoadTypeLib去加载这个ocx

所以我们hook了LoadRegTypeLib，在此函数内，调用LoadTypeLib来加载我们自带的flash插件。由于LoadRegTypeLib调用很少，所以性能比hookcreatefile好

最后发现该浏览器也hook了这个函数，由于之前不知道这个函数是什么用的，所以走了些弯路。看来对com还不够深入，欢迎兄弟们一起切磋讨论