flash插件 ie
大家好,我是你的好朋友思创斯。今天说一说flash插件 ie_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还不够深入,欢迎兄弟们一起切磋讨论
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
文章由思创斯整理,转载请注明出处:https://ispacesoft.com/78562.html