但事实上这一切尽在服务器眼中
玩家输入的任何游戏指令(-打头)
都会通过26号游戏协议包(F7 26 xx xx)发送到服务器

假如我们做了一个服务器插件
监控玩家使用的游戏指令
就可以达到一定的监测作弊效果

然后配合踢人功能惩罚作弊者…那么…

另外在分析魔兽协议的时候又学习了一下iocp模型
war3为每个连接创建了一个线程接收网络数据包
使用WSARecv接收数据
如果返回-1并且WSAGetLastError = ERROR_IO_PENDING
那么就使用GetQueuedCompletionStatus等待IO完成
另外通过lpCompletionKey结构，可以得知被等待的socket句柄和缓冲区

至此我们也可以猜测各种游戏平台的工作原理
hook socket把TCP改成UDP
hook connect返回成功
hook AcceptEx或其他。。
hook send通过sendto把数据传到服务器由服务器转发，要确保数据正确到达
hook WSARecv，貌似可以阻塞也可以不阻塞，总之数据来了就返回，如果不阻塞。那么再
hook GetQueuedCompletionStatus，等待数据到来
大体应该就是这样子，全是猜测，下一步可以构想一下自己实现的对战平台的网络模型

另外我想数据可以是由服务器中转的，也可以是用UDP穿墙技术实现的。
区别就是经过服务器中转。还可以多实现一些功能
比如聊天监控，作弊监控……

PingMonitor是一个专门监测网络线路ping值的小工具

你完全可以在命令行中使用 ping ip -t 代替它

但这个小工具使用起来将更加便捷直观。

这个工具可以同时监控2个ip

在Options.ini里.你可以设置电信、网通、铁通或局域网等任何IP地址

还可以个性化设定界面的颜色。

如果你的线路是ADSL，而且是你是个在线游戏爱好者。

我相信这个工具将会对你很有用。

还是改做调试器吧 :>

00401343: push 00402169h
00401348: push 00402162h
0040134D: call 004012C5h
004012C5: push ebp
004012C6: mov ebp , esp
004012C8: add esp , F4h
004012CB: lea eax , dword ptr [ebp-04h]
004012CE: push eax
004012CF: push 04h
004012D1: push 00h
004012D3: push dword ptr [ebp+08h]
004012D6: push 80000002h
004012DB: call RegOpenKeyExA (advapi32.dll)
004013B4: jmp RegOpenKeyExA (advapi32.dll)
……..: Out of watch limit, wait for ret …………
004012E0: or eax , eax
004012E2: jne 00401322h
004012E4: push dword ptr [ebp+0Ch]
004012E7: push dword ptr [ebp-04h]
004012EA: call RegDeleteKeyA (advapi32.dll)
004013A8: jmp RegDeleteKeyA (advapi32.dll)
……..: Out of watch limit, wait for ret …………
004012EF: lea eax , dword ptr [ebp-0Ch]
004012F2: push eax
004012F3: lea eax , dword ptr [ebp-08h]
004012F6: push eax
004012F7: push 00h
004012F9: push 00h
004012FB: push 01h
004012FD: push 00h
004012FF: push 00h
00401301: push dword ptr [ebp+0Ch]
00401304: push dword ptr [ebp-04h]
00401307: call RegCreateKeyExA (advapi32.dll)
004013A2: jmp RegCreateKeyExA (advapi32.dll)
……..: Out of watch limit, wait for ret …………
0040130C: push dword ptr [ebp-04h]
0040130F: call RegCloseKey (advapi32.dll)
0040139C: jmp RegCloseKey (advapi32.dll)
……..: Out of watch limit, wait for ret …………
00401314: cmp dword ptr [ebp-0Ch] , 02h
00401318: je 004012E4h
0040131A: push dword ptr [ebp-08h]
0040131D: call RegCloseKey (advapi32.dll)
0040139C: jmp RegCloseKey (advapi32.dll)
……..: Out of watch limit, wait for ret …………
00401322: leave
00401323: retn 0008h
00401352: push 40h
00401354: push 00402184h
00401359: push 00402171h
0040135E: push 00h
00401360: call MessageBoxA (user32.dll)
00401378: jmp MessageBoxA (user32.dll)
……..: Out of watch limit, wait for ret …………
00401365: push 00h
00401367: call ExitProcess (kernel32.dll)
0040137E: jmp ExitProcess (kernel32.dll)
……..: Out of watch limit, wait for ret …………

Dr.COM是北京城市热点开发的一款基于局域网的宽带接入服务器，广泛应用于高校校园网、小区宽带。

邮电学院南校区使用的就是Dr.COM服务器做宽带接入，使用了专用的客户端进行直通方式认证。

该客户端的功能很强大，但我们学校使用的客户端比较简单。主要做了如下2条限制。

绑定ARP缓冲中所有IP为非法MAC，阻塞局域网内TCPIP通讯，防止做共享网络。同时也无法玩局域网游戏(TCP/IP)

检测常见的共享网络的软件，并加以提示，停止激活Dr.COM网关。拒绝服务。

我们只需模拟Dr.COM客户端激活Dr.COM网关的方法。即可抛弃官方客户端及如上限制。

使用方法

拨号宽带连接，运行本软件。提示已经激活即可上网。

最小化后隐藏窗口，再次运行本软件可以调出窗口。

本软件没有设置自动运行，可以在程序->启动中创建快捷方式。

常见问题

1.如果提示无法绑定 UDP 61440 端口，请检查是否已经卸载原来的客户端。(官方客户端为ishare_user.exe进程)

2.如果提示接收数据2超时，请检查程序的连接是否被 Windows阻止。必要时可以关闭 Windows 的防火墙。

   XP环境下服务名为 Windows Firewall/Internet Connection Sharing (ICS)
   Vista/Win7环境下服务名为 Windows Firewall

  禁用这个服务即可。

所谓NBP是来自PXE文档的说法，全称 Network Bootstrap Program，也就是我以前理解的 PXE Boot File。他的作用就是 Hook Int 13h 虚拟一个硬盘，对硬盘的读写，通过 PXE API(通常使用UDP)定向到网络，返回数据给调用者，达到通过网络启动的目的。

一、NBP工作流程

1.Int 1Ah 获取PXE接口，这没什么说的。分2.0和2.1或以上版本2种区别，一般只需要兼容2.1就行。
2.PXENV_GET_CACHED_INFO 的3号功能，获取自己的IP和服务器IP。
3.PXENV_UDP_OPEN 初始化 UDP 网络接口。
4.Hook Int13h,I/O PXENV_UDP_READ/PXENV_UDP_WRITE
5.读 MBR 到 0000:7C00。
6.跳转 0000:7C00。

这些流程除了第四步Hook Int13h都不难，只是UDP部分需要注意处理丢包的问题。C/S用会话ID，很好解决。
另外那个UDP接口，收到大于4K的包，容易卡死在UDP_RECV里很久才返回一个错误。所以一次收发包最好小于4KB……
二、Hook Int13h

对于无盘启动XP，需要处理如下的功能号。并尽量按照标准来处理。。

FUN00: IO复位
FUN02: 读扇区
FUN03: 写扇区
FUN08: 读磁盘参数
FUN15: 读磁盘类型
FUN41: 检验扩展功能是否存在
FUN42: 扩展读
FUN43: 扩展写
FUN48: 扩展读磁盘参数

貌似对于无盘启动XP，处理写操作好像并不是必要的。一般情况XP在内核启动前不需要写操作。内核启动后加载磁盘驱动，然后才会有写操作，那时候已经不需要Int13h了。不过NTLDR是设计了写操作接口的，说不准，没准啥时候来个FUN03/43，所以最好还是处理了吧。

而且我在做NBP之前还在想，如果进入保护模式后，还使用Int13h怎么办？因为PXE文档中对保护模式中使用PXE API的说明很模糊。SDK中也没有例子，做起来会很烦，可是真正做的时候发现，在进入保护模式后，根本不需要Int13h了，系统会使用磁盘驱动来完成IO。

而且我发现XP在启动的时候并没有使用扩展Int13h功能，不过调试发现Win7的 Boot Sector/Mgr 会使用Int13x。

 
三、万恶的 CHS 寻址

（以下段落引用互联网。。。有更正）
—– Quote Start—–
到目前为止，人们常说的硬盘参数还是古老的 CHS (Cylinder/Head/Sector)参数。那么为什么要使用这些参数，它们的意义是什么？它们的取值范围是什么？
很久以前(long long ago …)，硬盘的容量还非常小的时候，人们采用与软盘类似的结构生产硬盘。也就是硬盘盘片的每一条磁道都具有相同的扇区数。由此产生了所谓的3D参数 (Disk Geometry)。即磁头数(Heads)，柱面数(Cylinders)，扇区数(Sectors)，以及相应的寻址方式。

其中:
磁头数(Heads) 表示硬盘总共有几个磁头，也就是有几面盘片，最大为 255 (用 8 个二进制位存储)；
柱面数(Cylinders) 表示硬盘每一面盘片上有几条磁道，最大为 1023(用 10 个二进制位存储)；
扇区数(Sectors) 表示每一条磁道上有几个扇区， 最大为 63 (用 6个二进制位存储)。
每个扇区一般是 512个字节，理论上讲这不是必须的，但好象没有取别的值的。

所以磁盘最大容量为：
256 * 1024 * 63 * 512 / 1048576 = 8064 MB ( 1M = 1048576 Bytes ) 或硬盘厂商常用的单位：
256 * 1024 * 63 * 512 / 1000000 = 8263 MB ( 1M = 1000000 Bytes )

在 CHS 寻址方式中，磁头，柱面，扇区的取值范围分别为 0到 Heads - 1， 0到 Cylinders - 1，1到 Sectors (注意是从1开始)。
—– Quote End—–

上述段落阐述了什么是 CHS 寻址，按照上文的理解Heads是磁头数单位应该是最大的，但是其实不是酱紫的~
按照寻址高低位排序，Cylinder > Head > Sector。

而且 H 不是表示硬盘总共有几个磁头，是最大磁头号。C 不是有几个柱面，是最大柱面号。要注意！

要把 CHS 转换成绝对地址，可以使用下面的公式
BlockAddr = ( Cylinder * NumberOfHeads + Head ) * SectorsPerTrack + Sector - 1;

NumberOfHeads 是磁盘的磁头数，假如最大磁头号码为255，那么NumberOfHeads = 256
SectorsPerTrack 是磁盘每磁道的扇区数 值为 63。

而且注意最后有一个-1。因为Sector取值范围是1-63而不是0-63。
Int13h 8号功能会返回 MAX HEAD，也就是最大磁头号。不要和上面公式的 NumberOfHeads 混淆。

 
四、万恶的 BootSector 程序

照理来说 XP 的 BootSector 应该使用Int13h的8号功能首先获取磁盘最大磁头号。
而他却使用了 BPB(BIOS Parameter Block) 结构中定义 HeadsPerCylinder。。。
注意这个 HeadsPerCylinder 不是最大磁头号而是磁头数，同上面公式中的 NumberOfHeads。
一般情况这里的值是FF，那么最大磁头号应该是 254！！

;======================================================
; BPB( BIOS Parameter Block )
;======================================================
BytesPerSector  DW ? ; 每个扇区的字节数 (512 1024 2048 4096)
SectorsPerCluster DB ? ; 每个簇的扇区数 ( 1 2 4 8 16 32 64 128 )
    ; 两者相乘不能超过32K(簇最大大小)
ReservedSectors  DW ? ; 从卷的第一个扇区开始的保留扇区数目
    ; 该值不能为0，对于FAT12/FAT16，该值通常为1
    ; 对于FAT32，典型值为32
NumberOfFATs  DB ? ; 卷上FAT数据结构的数目，该值通常应为2
RootEntries  DW ? ; 对于FAT12/FAT16,该值表示32字节目录项的数目
    ; 对于FAT32，该值必须为0
NumberOfSectors16 DW ? ; 该卷上的扇区总数，该字段可以为0，如果该字段
    ; 为0，则NumberOfSectors32不能为0；对于FAT32
    ; 该字段必须为0
MediaDescriptor  DB ? ; 介质类型
SectorsPerFAT16  DW ? ; 该字段标识一个FAT结构占有的扇区数（FAT12/FAT16）
    ; 对于FAT32卷，该字段必须为0
SectorsPerTrack  DW ? ; 用于INT 0×13中断的每个磁道的扇区数
HeadsPerCylinder DW ? ; 用于INT 0×13中断的每个柱面的磁头数
HiddenSectors  DD ? ; 包含该FAT卷的分区之前的隐藏扇区数
NumberOfSectors32 DD ? ; 该字段包含该卷上的所有扇区数目，对于FAT32，该字段
    ; 不为0；FAT12/FAT16可根据实际大小是否超过65536个扇
    ; 区数决定是否采用该字段

To Be Continued..

结合tdi又做出了网络虚拟盘。但无法应用于无盘网络系统，tdi在系统启动时无法使用，只能使用ndis，这样我还需要自己实现一个tcp协议……

由于以前没有做过关于richedit的开发，百度了下，需要使用OLE技术。也就是说，插入的图片都是一个OLE对象。而RICHEDIT则是一个OLE容器，相关链接如下。

How to insert a bitmap into an RTF document using the RichEdit control in Visual C++ 6.0
http://support.microsoft.com/default.aspx?scid=kb;en-us;220844

Animated Emoticons like those in MSN Messenger(英文版)
http://www.codeproject.com/KB/edit/AnimatedEmoticon.aspx

Animated Emoticons like those in MSN Messenger(中文版)
http://blog.csdn.net/dTianx/archive/2004/11/17/184949.aspx

DynamicGif作者blog
http://blog.csdn.net/kql01

第一个链接是微软提供的部分代码，只能用于插入BMP图片。使用了OleCreateFromFile创建的ole对象。

第二个、第三个链接都是dTianx写的，使用QQ的ImageOle.dll创建了ole对象。提供全部源代码。

第四个链接是一牛自己做的一个控件，导出函数InsertGifToRichedit2A可以方便地插入任意GIF。只提供DLL文件，而且只有1.21版本的，据说作者开发了1.4版本但他没有开放下载。
我对这4个方法逐一试验，结果发现这些方案都不可靠。下面我将详细的介绍，我假设各位读者从前没接触过RICHEDIT嵌入OLE这方面内容，2个星期前我也一无所知……

首先第一个不用说，只能插入BMP图片，不符合我们的要求，但这段代码已经可以让我们了解了插入一个OLE对象的全部步骤。

第三个DynamicGif使用导出函数InsertGifToRichedit2A，方便地插入了任意Gif图片，但是我发现他放出的这个1.21版本有问题，这个问题发生在拖动滚动条的时候，richedit会很不正常……

放弃使用了DynamicGif后我把所有的赌注加在了ImageOle上，可是可是待我把一切实现在汇编上的时候。我发现噩梦到来了……(-__-！夸张一小下)。

首先。上面的例子创建GifAnimator实例，获取IGifAnimator接口，IGifAnimator::LoadFromFile载入图片，然后调用神奇的IGifAnimator::TriggerFrameChange函数，调用IRichEditOle::InsertObject插入ole对象。顺理成章，但是这个例子有一个很明显的bug就是在显示透明gif的时候没有擦除背景。如下图所示。

另外当我实现在汇编上的时候我发现刷新有闪动问题，可能是InvalidateRect的第三个参数bErase被设置了TRUE，可是我调试发现ImageOle在调用这个api的时候bErase为False。郁闷地研究了好几天，终于发现这一切的一切居然是一个扩展风格导致的，WS_EX_TRANSPARENT，透明风格，而dTianx和qq的richedit的确有这个扩展风格。-_-!!! 当我给richedit加入这个风格后，刷新的确不闪了，但richedit背景与窗体相同，这就需要子类化richedit响应WM_ERASEBKGND消息，手工画背景为白色。

解决了这个后又开始着手解决显示透明gif的问题。这个问题应该源于GDI+的GdipImageDrawRectI函数，它只绘制了不透明的部分到DC上，我不知道qq是怎么解决的，我觉得应该有一个函数可以关掉GID+的这个特性:只绘制不透明部分到DC。但对GDI+非常不了解，找了好久没有找到。我想出来的解决方法是hook这段代码，加入一个创建白色刷子刷白色背景，然后再调用GdipImageDrawRectI绘制gif帧。这样每次绘制GIF帧背景都会被刷成白色。而且的确实现了~

在实验过程中，我还发现如果使用类名称为RICHEDIT20A版本的richedit会导致内存泄露问题，就是删除了已经插入的图片对象内存依然不释放，使用类名称为RICHEDIT版本的richedit没有此问题。而qq使用的是RICHEDIT20A，我复制了qq目录的riched20.dll仍然存在这个问题，我不知道qq有没有这个问题，以及他是怎么怎么解决的。

然后当我把代码转移到我的IM工程上我发现了更严重的问题。嵌入过多的ole会导致程序崩溃，崩溃点是riched20.dll，查看调用堆栈发现是其内部造成的，我无法查明原因。这个错误so奇怪，在实验工程上无论插入多少个图片都不会崩溃，一转移到IM工程上就有问题，我屏蔽了很多很多代码，最终发觉可能跟线程有关。在WM_INITDIALOG中插入多少个都没问题，在另外的线程插入就有问题，我想，把插入ole的代码放在窗口过程里。用SendMessage触发来添加，结果还是不行，很奇怪很奇怪。。。

还有另外一个很令我崩溃的问题，第一次创建richedit，插入gif图片可以，但当你销毁这个带有richedit的窗口，然后再创建，再次插入gif图片，图片不会动了（打开聊天窗口，插入gif，正常；关闭聊天窗口，打开聊天窗口，插入gif，gif不会动）。又另我百思不得其解。为此我调试了ImageOle，晓得了ImageOle的原理。

ImageOle读取了一个图片后，依赖接口IViewObject::OnDraw实现刷新ole区域显示gif的不同帧。而这个OnDraw是需要InvalidateRect触发的。这就需要一个定时器来定时调用InvalidateRect实现刷新，这个定时器是由ImageOle内部创建的，是在CreateInstance的时候。而且他有个判断，如果已经创建过（句柄不为0），就不需要再创建了。当我销毁我的聊天窗口的时候，这个定时器居然神奇般地不见了……所以再次插入gif就不能自主动态刷新gif了。dTianx的mfc工程，他并未销毁窗口，用spy++可以看到当关闭窗口的时候，窗口只是变为了invisable……所以没有这个bug。

这种种的问题逼迫我去寻找其他的替代DLL。

我发现浩方平台也有个ImageOle，接口名换了，但也有LoadFromFile,TriggerFrameChange，和QQ的ImageOle惊人的相似，好神奇~两者难道有某种关联？ImageOle的开发者究竟是谁呢？不管这些，我实验调用浩方的ImageOle.dll也不成。然后又寻找了飞信、百度Hi……

找到了很多。都用不明白。

这迫使我选择另一条崎岖的路。

另一条最有可能成功的路。。

自己造个ActiveX实现OLE对象嵌入。。

需要编程实现n个COM接口
IDispatch
IOleObject
IOleInPlaceObject
IOleInPlaceActiveObject
IOleControl
IDataObject
IProvideClassInfo
IPersistStorage
IPersistStreamInit
IPersistPropertyBag
IViewObject2
ISpecifyPropertyPages
ICategorizeProperties
IConnectionPointContainer
IRunnableObject

接口太多了，工程量巨大，我肯定自己搞不定的，不过好在印象里masm32包里有个asmctrl的工程，是一个activex控件，可以被vb调用，肯定已经实现了这些东西，找来masm32 v9果然有。尝试把他插入richedit里，发现插入1个以上ole的绘制就有问题。看readme可以知道这个工程的作者。

他就是japheth，一个德国的汇编超人……

作品有牛x闪闪的COMView和牛x闪闪闪的masm兼容编译器JWasm。otz

他对COM的研究可谓是非常的透彻了，不然怎么可能敢用汇编写ActiveX~~

超人的网站 http://www.japheth.de

网站的 COM & Assembly 栏目里有一个ASMCtrl工程。版本是2.5.5，v9里的可能是1.0版本，看历史记录可知后续版本修正了bugs。而且2.0版本后使用了大量的宏，因为这些宏，我读他的代码变得非常非常难。。看了超人japheth的代码我才知道汇编原来是这么这么玩的，太牛x的……太令人无语了。看不懂，给超人写信要来了1.3的版本，1.3代码比2.x好理解，只用了少量的宏，不过编译后插入richedit依然存在bug。无奈只有使用2.5.5版本当模板做我的PicOlePlus了。

然后结合我对调试ImageOle得出的经验和对GDIPlus的学习。很费力地修改了ASMCtrl工程，得到了伟大的PicOlePlus.dll这个东东

下面是我做的一些主要更改。

1.CAsmClass.inc里面添加一些类私有变量，还需要在CAsmClass的MEMBER里申明

  hGdiplus dd ?
  pImage dd ?
  dwWidth dd ?
  dwHeight dd ?
  dwFrameCount dd ?
  pPropertyItem dd ? ;id len type pvalue[]
  dwFrame0Tick dd ?

2.在CAsmClass::Create里面初始化GDI+，CAsmClass::Destroy里面释放图像，释放GDI+。代码略

3.修改IAsmClass的接口，添加了一个LoadFromFile方法，调用LoadImageFile函数
LoadImageFile Proc lpszFile
  Local wszFile[260]:WORD
  
  invoke MultiByteToWideChar,CP_OEMCP,MB_PRECOMPOSED,lpszFile,-1,addr wszFile,255
  invoke GdipLoadImageFromFile,addr wszFile,addr m_pImage
  .if !eax
   invoke GdipGetImageWidth,m_pImage,addr m_dwWidth
   invoke GdipGetImageHeight,m_pImage,addr m_dwHeight
   invoke SetOleExtent   ;设置Ole尺寸
   invoke SendViewChange@CAsmClass,ebx ;!!! 通知OLE容器OLE大小改变
   invoke IsAnimatedGIF
   xor eax,eax
  .endif
  ret
LoadImageFile EndP

IsAnimatedGIF Proc
  Local dwDimensionCount
  Local pDimensionIDs
  Local nSize
  
  invoke GdipImageGetFrameDimensionsCount,m_pImage,addr dwDimensionCount
  mov eax,dwDimensionCount
  shl eax,4
  invoke LocalAlloc,LPTR,eax
  mov pDimensionIDs,eax
  invoke GdipImageGetFrameDimensionsList,m_pImage,pDimensionIDs,dwDimensionCount
  invoke GdipImageGetFrameCount,m_pImage,pDimensionIDs,addr m_dwFrameCount
  invoke GdipGetPropertyItemSize,m_pImage,PropertyTagFrameDelay,addr nSize
  .if !eax
   invoke LocalAlloc,LPTR,nSize
   mov m_pPropertyItem,eax
   invoke GdipGetPropertyItem,m_pImage,PropertyTagFrameDelay,nSize,m_pPropertyItem
  .endif
  invoke LocalFree,pDimensionIDs
  invoke timeGetTime
  mov m_dwFrame0Tick,eax
  ret
IsAnimatedGIF EndP

SetOleExtent Proc ;计算尺寸
  pushad
  invoke GetDC,0
  mov esi,eax
  invoke GetDeviceCaps, esi, LOGPIXELSX
  push eax
  mov eax,m_dwWidth
  mov m_pixelExtent.cx_, eax
  mov ecx,HIMETRIC_PER_INCH
  mul ecx
  pop ecx
  xor edx,edx
  div ecx
  mov m_himetricExtent.cx_, eax
  
  invoke GetDeviceCaps, esi, LOGPIXELSY
  push eax
  mov eax,m_dwHeight
  mov m_pixelExtent.cy, eax
  mov ecx,HIMETRIC_PER_INCH
  mul ecx
  pop ecx
  xor edx,edx
  div ecx
  mov m_himetricExtent.cy, eax
  invoke DeleteObject,esi
  popad
  ret
SetOleExtent EndP

4.修改IViewObject::OnDraw的代码调用DrawImage

sIID_FrameDimensionTime TEXTEQU <{06aedbd6dH, 03fb5H, 0418aH, {083h,0a6h,07fh,045h,022h,09dh,0c8h,072h}}>
FrameDimensionTime GUID sIID_FrameDimensionTime

DrawImage Proc uses esi edi ebx hDC,X,Y
  Local dwTicks
  Local hGraphics
  Local rt:RECT
  Local hScrDC,hTempDC,hBitmap
  
  .if m_pPropertyItem  ;通过帧延迟数据和已经经过的时间计算当前应该显示的帧
   invoke timeGetTime ;timeGetTime精度是1ms
   sub eax,m_dwFrame0Tick
   xor edx,edx
   mov ecx,10
   div ecx
   mov dwTicks,eax
   
   mov esi,m_pPropertyItem
   mov esi,dword ptr [esi+12]
   xor edi,edi
   .While TRUE
    mov eax,[esi+edi*4]
    .Break .if dwTicks < eax
    sub dwTicks,eax
    inc edi
    .if edi == m_dwFrameCount
     xor edi,edi
    .endif
   .EndW
   
   invoke GdipImageSelectActiveFrame,m_pImage,addr FrameDimensionTime,edi ;选择帧
  .endif
  
  invoke GetDC,0  ;创建缓冲dc
  mov hScrDC,eax
  invoke CreateCompatibleDC,hScrDC
  mov hTempDC,eax
  invoke CreateCompatibleBitmap,hScrDC,m_dwWidth,m_dwHeight
  mov hBitmap,eax
  invoke SelectObject,hTempDC,hBitmap
  invoke DeleteObject,eax
  invoke DeleteDC,hScrDC
  
  invoke SetRect,addr rt,0,0,m_dwWidth,m_dwHeight ;填充背景为白色
  invoke GetStockObject,WHITE_BRUSH
  invoke FillRect,hTempDC,addr rt,eax
  
  invoke GdipCreateFromHDC,hTempDC,addr hGraphics
  invoke GdipDrawImageRectI,hGraphics,m_pImage,0,0,m_dwWidth,m_dwHeight ;画gif帧
  invoke GdipDeleteGraphics,hGraphics
  
  invoke BitBlt,hDC,X,Y,m_dwWidth,m_dwHeight,hTempDC,0,0,SRCCOPY
  invoke DeleteObject,hBitmap
  invoke DeleteDC,hTempDC
  ret
DrawImage EndP
这样，一个支持gif的OLE组件就搞定了，哈哈哈~不过这里没有刷新，刷新我给弄到外面去了。有外面代码控制刷新。

下面是插入GIF的代码

InsertObject Proc uses esi edi ebx hWnd,ID,lpszFile
  Local lpOleInterface
  Local lpLockBytes
  Local lpStorage
  Local lpClientSite
  Local ppv
  Local lpOleObject
  Local lpPicOlePlus
  Local clsid:GUID
  Local reo:REOBJECT
  
  mov lpOleInterface,0
  mov lpLockBytes,0
  mov lpStorage,0
  mov lpClientSite,0
  mov ppv,0
  mov lpOleObject,0
  mov lpPicOlePlus,0
  
  invoke SendDlgItemMessage,hWnd,ID,EM_GETOLEINTERFACE,0,addr lpOleInterface
  cmp lpOleInterface,0
  jz exit
  
  invoke CreateILockBytesOnHGlobal,NULL,TRUE,addr lpLockBytes
  cmp lpLockBytes,0
  jz exit
  
  invoke StgCreateDocfileOnILockBytes,lpLockBytes,STGM_SHARE_EXCLUSIVE or STGM_CREATE or STGM_READWRITE,0,addr lpStorage
  cmp lpStorage,0
  jz exit
  
  mov esi,lpOleInterface
  mov esi,dword ptr [esi]
  assume esi:ptr IRichEditOle
  invoke [esi].GetClientSite,lpOleInterface,addr lpClientSite
  cmp lpClientSite,0
  jz exit
  
  invoke CoInitializeEx,NULL,COINIT_APARTMENTTHREADED
  invoke CoCreateInstance,addr IID_PicOlePlus,0,CLSCTX_INPROC_SERVER or CLSCTX_INPROC_HANDLER or CLSCTX_LOCAL_SERVER,addr IID_IUnknown,addr ppv
  invoke OleRun,ppv
  
  mov ecx,ppv
  mov ecx,[ecx]
  invoke [ecx][IUnknown.QueryInterface],ppv,addr IID_IPicOlePlus,addr lpPicOlePlus
  cmp lpPicOlePlus,0
  jz exit
  
  mov eax,ppv
  mov eax,[eax]
  invoke [eax][IUnknown.Release],ppv
  
  mov edi,lpPicOlePlus
  mov edi,dword ptr [edi]
  assume edi:ptr IPicOlePlus
  
  invoke [edi].LoadFromFile,lpPicOlePlus,lpszFile
  cmp eax,0
  jnz exit
  
  invoke [edi].QueryInterface,lpPicOlePlus,addr IID_IOleObject,addr lpOleObject
  cmp lpOleObject,0
  jz exit
  
  invoke OleSetContainedObject,lpOleObject,TRUE
  .if eax
   ret
  .endif
  
  mov edi,lpOleObject
  mov edi,dword ptr [edi]
  assume edi:ptr IOleObject
  invoke [edi].GetUserClassID,lpOleObject,addr clsid
  
  mov reo.cbStruct,sizeof reo
  mov reo.cp,-1
  invoke RtlMoveMemory,addr reo.clsid,addr clsid,sizeof clsid
  m2m reo.poleobj,lpOleObject
  m2m reo.pstg,lpStorage
  m2m reo.polesite,lpClientSite
  mov reo.sizel.x,0
  mov reo.sizel.y,0
  mov reo.dvaspect,1 ;DVASPECT_CONTENT
  mov reo.dwFlags,2 ;REO_BELOWBASELINE
  mov reo.dwUser,0
  invoke [esi].InsertObject,lpOleInterface,addr reo
  
exit:  .if lpClientSite
   mov eax,lpClientSite
   mov eax,[eax]
   invoke [eax][IUnknown.Release],lpClientSite
  .endif
  
  .if lpOleObject
   mov eax,lpOleObject
   mov eax,[eax]
   invoke [eax][IUnknown.Release],lpOleObject
  .endif
  
  .if lpStorage
   mov eax,lpStorage
   mov eax,[eax]
   invoke [eax][IUnknown.Release],lpStorage
  .endif
  
  .if lpPicOlePlus
   mov eax,lpPicOlePlus
   mov eax,[eax]
   invoke [eax][IUnknown.Release],lpPicOlePlus
  .endif
  
  .if lpLockBytes
   mov eax,lpLockBytes
   mov eax,[eax]
   invoke [eax][IUnknown.Release],lpLockBytes
  .endif
  ret
InsertObject EndP
在窗口过程中注册一个定时器调用RedrawObject来刷新。这个代码和ImageOle的有些不同。

HiMetricX2Pixel Proc dwHiMetricX
  Local hDC
  
  invoke GetDC,0
  mov hDC,eax
  invoke GetDeviceCaps,hDC,LOGPIXELSX
  push eax
  invoke DeleteObject,hDC
  pop eax
  mov ecx,dwHiMetricX
  mul ecx
  xor edx,edx
  mov ecx,2540
  div ecx
  .if edx
   inc eax
  .endif
  ret
HiMetricX2Pixel EndP

RedrawObject Proc uses esi edi ebx hWnd,ID
  Local hRichEdit
  Local lpOleInterface
  Local dwObjectCount
  Local reo:REOBJECT
  Local szTemp[256]:BYTE
  Local pt:POINT
  Local rcClient:RECT
  Local rc:RECT
  Local IsInClient
  
  invoke GetDlgItem,hWnd,ID
  mov hRichEdit,eax
  
  invoke SendMessage,hRichEdit,EM_GETOLEINTERFACE,0,addr lpOleInterface
  cmp lpOleInterface,0
  jz exit
  
  mov esi,lpOleInterface
  mov esi,[esi]
  assume esi:ptr IRichEditOle
  
  invoke [esi].GetObjectCount,lpOleInterface ;取OLE对象数量
  mov dwObjectCount,eax
  
  invoke GetClientRect,hRichEdit,addr rcClient
  
  xor ebx,ebx     ;循环获取每个OLE然后根据需要刷新之
  .While ebx < dwObjectCount
   mov IsInClient,0
   
   invoke RtlZeroMemory,addr reo,sizeof reo
   mov reo.cbStruct,sizeof reo
   invoke [esi]._GetObject,lpOleInterface,ebx,addr reo,1 ;1 = REO_GETOBJ_POLEOBJ
   
   invoke SendMessage,hRichEdit,EM_POSFROMCHAR,addr pt,reo.cp
   m2m rc.left,pt.x
   m2m rc.top,pt.y
   m2m rc.right,pt.x
   invoke HiMetricX2Pixel,reo.sizel.x
   add rc.right,eax
   m2m rc.bottom,rcClient.bottom
   
   mov eax,reo.poleobj
   mov eax,[eax]
   invoke [eax.IOleObject.Release],reo.poleobj
   
   invoke PtInRect,addr rcClient,rc.left,rc.top
   .if eax
    inc IsInClient
    jmp @f
   .endif
   
   invoke PtInRect,addr rcClient,rc.right,rc.top
   .if eax
    inc IsInClient
    jmp @f
   .endif
   
   invoke PtInRect,addr rcClient,rc.left,rc.bottom
   .if eax
    inc IsInClient
    jmp @f
   .endif
   
   invoke PtInRect,addr rcClient,rc.right,rc.bottom
   .if eax
    inc IsInClient
    jmp @f
   .endif
   
@@:   
   .if IsInClient
    invoke InvalidateRect,hRichEdit,addr rc,0
   .endif
   inc ebx
  .EndW
exit:  
  ret
RedrawObject EndP

最终效果如下

测试工程打包下载 http://www.deadc0de.com/wp-content/uploads/2009/05/richole2.rar

HANDLE LoadImage(
    HINSTANCE hinst,  // handle of the instance that contains the image
    LPCTSTR lpszName, // name or identifier of image
    UINT uType, // type of image
    int cxDesired, // desired width
    int cyDesired, // desired height
    UINT fuLoad // load flags
   );
设置此函数的 cxDesired cyDesired 参数实现缩放，效果较好。但是这个函数只能从文件或资源中获取位图。不方便用于已读入内存的位图。

而 StretchDIBits 可以实现但是效果又不理想。这使我有了研究 LoadImage 内部的冲动…… -_-!

首先看了 ReactOS 中的 LoadImage，他对 BITMAP 类型的文件使用 LoadBitmapImage 处理。

      case IMAGE_BITMAP:
         return LoadBitmapImage(hinst, lpszName, fuLoad);

忽略了 cxDesired 和 cyDesired。显然这一点和 Windows 不同。我只好使用OD调试 Windows 的 user32.dll。

我假设 LoadImage 内部使用 StretchDIBits 进行缩放，对 StretchDIBits 下断。果然断了下来。但发觉函数的参数不对。

（原图像宽高均40，cxDesired,cyDesired设置为30）

0012F318   77D1CAB6  /CALL 到 StretchDIBits 来自 user32.77D1CAB0
0012F31C   E8011199  |hDC = E8011199
0012F320   00000000  |XDest = 0
0012F324   00000000  |YDest = 0
0012F328   0000001E  |WidthDest = 1E (30.)
0012F32C   0000001E  |HeightDest = 1E (30.)
0012F330   00000000  |XSrc = 0
0012F334   00000000  |YSrc = 0
0012F338   0000001E  |WidthSrc = 1E (30.)
0012F33C   0000001E  |HeightSrc = 1E (30.)
0012F340   001493C8  |pBits = 001493C8
0012F344   00148FA0  |pBitmapinfo = 00148FA0
0012F348   00000000  |Usage = DIB_RGB_COLORS
0012F34C   00CC0020  \ROP = SRCCOPY

参数中源宽高和目标宽高是相同的，都是缩放后的30，明显在调用这个函数之前就已经处理好了位图数据。

位图缓冲区是 001493C8，重新调试了1次后发现这个地址不变。然后我对这个地址下了硬件访问断点以得到缩放位图数据的函数。运行，断在了下面的位置

77D21C35    52              push    edx
77D21C36    03C8            add     ecx, eax
77D21C38    FF71 03         push    dword ptr [ecx+3]
77D21C3B    FF31            push    dword ptr [ecx]
77D21C3D    FF70 03         push    dword ptr [eax+3]
77D21C40    FF30            push    dword ptr [eax]
77D21C42    E8 EFB7FFFF     call    77D1D436    <<<< 插值算法，根据4个像素点求1个像素点
77D21C47    8BC8            mov     ecx, eax
77D21C49    C1E9 10         shr     ecx, 10
77D21C4C    880F            mov     byte ptr [edi], cl   <<<<< EIP 断在这里
77D21C4E    47              inc     edi
77D21C4F    8827            mov     byte ptr [edi], ah
77D21C51    47              inc     edi
77D21C52    8807            mov     byte ptr [edi], al

用IDA分析这个函数，发现这个函数有很多参数 -_-! SO MANY…

int __stdcall sub_77D21BD0(int a1, int BufferSrc, int LineBytes, int a4, int a5, int a6, int a7, int BufferDst, int a9, int DestWidth, int DestHeight)

有一些参数懒得猜测其意，继续向上分析

交叉参考发现这个函数在一个函数表里……用OD返回到调用他的函数。发现是这样的

77D1D71B    FF10            call    dword ptr [eax]    <<<< 是从这里进入 sub_77D21BD0
77D1D71D    834D FC FF      or      dword ptr [ebp-4], FFFFFFFF
77D1D721    33C0            xor     eax, eax
77D1D723    40              inc     eax
77D1D724    E8 D7AEFFFF     call    77D18600
77D1D729    C2 1000         retn    10

retn 10 可知此函数有 4 个参数。执行到返回。来到了下面的位置

77D1D5DF    56              push    esi
77D1D5E0    53              push    ebx
77D1D5E1    FF75 2C         push    dword ptr [ebp+2C]
77D1D5E4    8943 04         mov     dword ptr [ebx+4], eax
77D1D5E7    8B45 18         mov     eax, dword ptr [ebp+18]
77D1D5EA    FF75 30         push    dword ptr [ebp+30]
77D1D5ED    8943 08         mov     dword ptr [ebx+8], eax
77D1D5F0    66:8B45 FC      mov     ax, word ptr [ebp-4]
77D1D5F4    66:8943 0E      mov     word ptr [ebx+E], ax
77D1D5F8    E8 24000000     call    77D1D621
77D1D5FD    85C0            test    eax, eax  <<<< 返回到这里

对他的上一句 call 下断点重新运行程序。得到4个参数

0012F33C   00146C20
0012F340   00AD0036
0012F344   00146C70
0012F348   00147098

查看内存后我发现了这个函数的原型

int __stdcall sub_77D1D621(BITMAPINFO *SrcHdr, PVOID *lpSrcBits, BITMAPINFO *DstHdr, PVOID *lpDstBits)

这样。我们就可以使用 sub_77D1D621 这个内部函数缩放位图数据啦。

可是怎么使用呢。由于是user32内部函数，没有导出。在不同的操作系统这个函数的位置是不同的。我当初想过把这个函数抠出来独立实现，可是发现这个代码写的实在是有点搞……里面利用了一些函数表，而且一些代码乱乱的。不好移植，所以干脆就使用特征码的方法搜索吧！ -_-!

查看了 win2000/xp/2003/vista 的 user32.dll
，发现除win2000的函数开头有些不一致，其他版本的win大体还是相同的！

77D1D621    6A 28           push    28
77D1D623    68 30D7D177     push    77D1D730
77D1D628    E8 93AFFFFF     call    77D185C0
77D1D62D    33FF            xor     edi, edi
77D1D62F    8B4D 08         mov     ecx, dword ptr [ebp+8]
77D1D632    3979 10         cmp     dword ptr [ecx+10], edi

这是winxp sp3开头的6行代码。由于2、3行涉及到了变量我们使用后三行作为特征码

特征码为 33 FF 8B 4D 08 39 79 10 共8个字节。

下面是搜索函数

GetStretchBits Proc uses esi edi ebx
Local hUser32

invoke GetModuleHandle,CTEXT(”user32.dll”)
mov edi,eax

@@: .if dword ptr [edi] == 4d8bff33h && dword ptr [edi+4] == 10793908h
.if word ptr [edi-12] == 286Ah ;winxp/2003/vista
lea eax,[edi-12]
ret
.endif
.if dword ptr [edi-28h] == 6AEC8B55h ;win2000
lea eax,[edi-28h]
ret
.endif
mov eax,0 ;无法识别
ret
.endif
inc edi
jmp @b

ret
GetStretchBits EndP

对于 40×40 的一个QQ头像，缩放至20×20，与 Photoshop(两次立方平滑)/StretchDIBits 对比效果如下

从左到右依次为

1.源图像
2.user32.LoadImage 内部函数处理
3.Photoshop(两次立方平滑)
4.StretchDIBits

 
下面我给出大致的测试代码片段
测试平台 LENOVO_XP_PRO_SP3_CHS_090416
.586
.Model Flat,StdCall
Option CaseMap :None

Include Windows.inc
Include User32.inc
Include Kernel32.inc
Include Gdi32.inc

IncludeLib User32.lib
IncludeLib Kernel32.lib
IncludeLib Gdi32.lib

.Code
GetStretchBits Proc uses esi edi ebx
  Local hUser32
  
  invoke GetModuleHandle,CTEXT(”user32.dll”)
  mov edi,eax
  
@@:  .if dword ptr [edi] == 4d8bff33h && dword ptr [edi+4] == 10793908h
   .if word ptr [edi-12] == 286Ah
    lea eax,[edi-12]
    ret
   .endif
   .if dword ptr [edi-28h] == 6AEC8B55h
    lea eax,[edi-28h]
    ret
   .endif
   mov eax,0
   ret
  .endif
  inc edi
  jmp @b
  
  ret
GetStretchBits EndP

Start Proc
 Local hFile,dwFileSize,dwRead
 Local lpBI,lpBits
 Local lpSrcBuffer,lpDstBuffer
 Local bi:BITMAPINFOHEADER
 Local hDC
 
 invoke CreateFile,CTEXT(”NEWFACE\24.bmp”),GENERIC_ALL,FILE_SHARE_READ,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0 ;40×40 24Bit Bitmap
 mov hFile,eax
 invoke GetFileSize,hFile,0
 mov dwFileSize,eax
 invoke LocalAlloc,LPTR,65536
 mov lpSrcBuffer,eax
 invoke ReadFile,hFile,lpSrcBuffer,dwFileSize,addr dwRead,0 ;读入lpSrcBuffer
 invoke CloseHandle,hFile
 
 mov esi,lpSrcBuffer
 add esi,[esi][BITMAPFILEHEADER.bfOffBits]
 mov lpBits,esi  ;定位位图数据区
 
 mov esi,lpSrcBuffer
 add esi,sizeof BITMAPFILEHEADER
 mov lpBI,esi  ;定位 源 BITMAPFILEHEADER
 
 invoke RtlMoveMemory,addr bi,lpBI,sizeof BITMAPINFOHEADER ;复制一份 BITMAPFILEHEADER 当作 目标 BITMAPFILEHEADER
 mov bi.biWidth,20  ;设置缩放宽
 mov bi.biHeight,20  ;设置缩放高
 
 invoke LocalAlloc,LPTR,65536 ;申请目标缓冲区
 mov lpDstBuffer,eax
 
 invoke GetStretchBits  ;获取函数地址
 .if eax
  push lpDstBuffer
  lea ecx,bi
  push ecx
  push lpBits
  push lpBI
  call eax  ;调用之
 .endif
 
 invoke GetDC,0   ;获取屏幕 DC
 mov hDC,eax
 
 invoke StretchDIBits,hDC,0,0,20,20,0,0,20,20,lpDstBuffer,addr bi,DIB_RGB_COLORS,SRCCOPY ;画在屏幕 0,0 处
 invoke ExitProcess,0
Start EndP
End Start

(完)

使用WordPress程序

欢迎大家常来玩

嘿嘿~