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

e内核自带flash方案要比webkit复杂Ie的flash插件是个ocx,也是com组件。WindowsCom组件的加载过程如下:1、通过组件的DllRegisterServer注册com组件,会在注册表生成com组件的路径,guid,progid,threadtype等等2、Client通过guid查找到注册表中com组件的地址,loadlibrary加载这个组件,调用c

大家好,又见面了,我是你们的朋友全栈君。

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

Ieflash插件是个ocx,也是com组件。

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

1、 通过组件的DllRegisterServer注册com组件,会在注册表生成com组件的路径,guidprogidthreadtype等等

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

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

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

第一阶段

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

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

第二阶段:

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

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

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

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

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

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

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

windbg中输入

bp ole32!CoGetClassObject

bp Kernel32LoadLibraryEx

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

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

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

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

第三阶段:

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

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

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

通过研究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找到flashocx路径,然后通过LoadTypeLib去加载这个ocx

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

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

 

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/127620.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号