时间戳

首页 > 解决方案 > 使用 VTable hacking 使用标准模块中的方法重载 COM 类方法

vba - 使用 VTable hacking 使用标准模块中的方法重载 COM 类方法

问题描述

快速提问 - 我刚刚通过使用低级复制内存 API 更改其 VTable 中的条目来测试类的覆盖方法。

背景

我取得了一些成功，如果它们具有相同的签名，则可以交换类的 VTable 中的 2 个条目。所以像这样的类定义：

Option Explicit

Public Sub Meow()
    Debug.Print "Meow"
End Sub

Public Sub Woof()
    Debug.Print "Woof"
End Sub

... 生成一个像这样的 VTable：

虚拟表

...我可以交换位置 7 和 8 的条目以进行cls.Meow打印Woof，反之亦然。我还可以将一个类的 VTable 中的条目与完全不同的 VTable 交换（前提是我不尝试this通过调用来取消引用隐式指针Me.anything）

所以我可以再上课

Option Explicit

Public Sub Tweet()
    Debug.Print "Tweet"
End Sub

并交换Woof来自另一个的行为Tweet。不太复杂，如果有人需要，我可以分享代码。

我不能做什么...

...但是，是否弄清楚如何将类方法与标准模块中的方法交换？

根据这篇文章，似乎构建 VBA 的 COM 机制需要 VBA 隐藏的两个类方法：

所以我认为

Public Sub Meow()

在类模块Class1中相当于

Public Function Meow(ByVal this As LongPtr) As Long

我也试过

Public Function Meow(ByRef meObj As Class1) As Long
Public Function Meow(ByRef meObj As Class1) As LongPtr 'but HResult is 32 bit int
Public Sub Meow(ByVal this As LongPtr)

等但是当我尝试从 VTable 调用该方法时，VBA 总是崩溃。所以我有点茫然。我想知道 64 位计算机上的情况是否有所不同，或者标准模块函数是否对调用堆栈做了一些奇怪的事情。问题是我已经看到了整个 VTable 由标准模块函数组装而成的代码示例，所以我知道这是可能的，但只是不确定如何正确转换签名

如何使用标准模块中定义的方法覆盖 VTable 条目？

标签： vbacom64-bitvtableiunknown

解决方案

我对你的问题的评论只是部分正确。我仍然相信Me关键字在防止类方法“重定向”到标准 .bas 模块中的方法方面发挥作用。但这仅适用于早期绑定。

IDispatch::Invoke 实际上可以毫无问题地调用 .bas 模块中的方法。您的初始方法签名是正确的：

Public Function Meow(ByRef meObj As Class1) As Long

Class1代码：

Option Explicit

Public Sub Meow()
    Debug.Print "Meow"
End Sub

Public Sub Woof()
    Debug.Print "Woof"
End Sub

标准 .bas 模块中的代码：

Option Explicit

Sub Test()
    Dim c As Object 'Must be late-binded!
    Dim vTblPtr As LongPtr
    Dim vTblMeowPtr As LongPtr
    Dim originalMeow As LongPtr
    '
    Set c = New Class1
    c.Meow 'Prints "Meow" to the Immediate Window
    '
    'The address of the virtual table
    vTblPtr = MemLongPtr(ObjPtr(c))
    '
    'The address of the Class1.Meow method within the virtual table
    vTblMeowPtr = vTblPtr + 7 * PTR_SIZE
    '
    'The current address of the Class1.Meow method
    originalMeow = MemLongPtr(vTblMeowPtr)
    '
    'Replace the address of Meow with the one in a .bas module
    MemLongPtr(vTblMeowPtr) = VBA.Int(AddressOf Moew)
    '
    c.Meow 'Prints "Meow in .bas" to the Immediate Window
    '
    'Revert the original address
    MemLongPtr(vTblMeowPtr) = originalMeow
    '
    c.Meow 'Prints "Meow" to the Immediate Window
End Sub

Public Function Moew(ByVal this As Class1) As Long
    Debug.Print "Meow in .bas"
End Function

我使用LibMemory进行内存操作。

如果您将Meow类方法更改为 aFunction而不是 a，Sub那么您需要在 .bas 模块中ByRef的方法内的参数列表末尾有一个额外的参数。Meow

编辑#1

我想到了下面评论中讨论的问题，我能想到的唯一原因是 IDispatch 仅适用于指向 IUnknown 接口的指针。

这意味着：

Public Function Meow(ByRef this As Class1) As Long

将使应用程序崩溃

但是，这有效：

Public Function Moew(ByVal this As Class1) As Long
    Debug.Print "Meow in .bas"
End Function

因为传递ByVal会强制 IUnknown 上的 QueryInterface 和 AddRef （退出范围时使用 Release）

这也有效：

Public Function Moew(ByRef this As IUnknown) As Long
    Debug.Print "Meow in .bas"
End Function

编辑#2

为再次编辑表示歉意。

Invoke 方法不适用于指向 IUnknown 的指针。它正在使用指向 IDispatch 的指针。这可以通过以下方式检查：

Public Function Moew(ByVal this As LongPtr) As Long
    Debug.Print this
    Debug.Print "Meow in .bas"
End Function

这会将 ptr 打印到 IDispatch 接口。那么，为什么会ByRef this As Class1失败呢？为什么做ByVal this As Class1和ByRef this As IUnknown工作？

ByRef this As Class1
我相信 VB 无法访问 VarPtr(this) 地址，因此我们正在读取我们不应该读取的内存。IUnknown 接口上没有额外的 AddRef 或 Release，因为该方法永远不会使用此声明调用。当 Invoke 试图调用该方法时，应用程序就会崩溃。

ByVal this As Class1
该方法只是创建一个 VB 变量（在 VB 内存空间上）并调用 AddRef

ByRef this As IUnknown
由于这不是双接口，因此完成了对 QueryInterface 和 AddRef 的调用。'this' 的内存地址在本地内存空间上，与第二个示例相同。

推荐阅读