大家好，又见面了，我是你们的朋友全栈君。
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还不够深入，欢迎兄弟们一起切磋讨论
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/127620.html原文链接：https://javaforall.net
