MASM 修复 DLL 中的 64 位截断
我正在通过将 Adobe Flash ocx 加载到我的 C++ 程序中来使用它。 ocx 应该是 64 位的，但由于某种原因，当我使用 x64 平台进行编译时，它会出现问题。我已阅读此内容，发现某些函数可能通过某些结构接收 DWORD userData 而不是 void* userData，然后将其转换为对象指针。这在 32 位环境中工作正常，但在 64 位环境中崩溃。
导致崩溃的 ocx 内部函数调用的反汇编如下：
mov ecx,r8d
第一个操作仅将低 32 位从 R8D 复制到 ECX（ECX 是 32-少量）。
cmp dword ptr [rcx+11BCh],0
第二个操作访问 64 位寄存器，其中低 32 位包含正确地址，高 32 位包含一些垃圾。当然会导致崩溃。
解决方案
我读到，一种可能的解决方案是执行以下操作：
创建一个包含以下代码的 asm 文件：
<前><代码>nop 不 不 mov ecx,r8d cmp 双字指针 [rcx+11BCh],0 不 不 不 mov rcx,r8d // 我在这里用 rcx 替换了 ecx cmp 双字指针 [rcx+11BCh],0使用此 asm 文件和 MASM.exe 构建 obj 文件
- 打开使用十六进制编辑器打开 .obj 文件，并找到代表 nop 的 90。
- 在 Flash ocx 中，找到 nop 之间的第一个字节字符串，并将其替换为 nop 之后的新字节字符串。这会将其从 32 位函数调用更改为 64 位函数调用。
问题
我尝试通过制作以下asm文件并使用ml64.exe构建它（我没有masm.exe，但我认为ml.exe是新的它的 32 位版本，并且此代码只能使用 ml64.exe 构建，可能是因为仅使用 64 位运算符？）：
TITLE: Print String Assembly Program (test.asm)
.Code
main Proc
nop
nop
nop
mov ecx,r8d
cmp dword ptr [rcx+11BCh],0
nop
nop
nop
mov rcx,r8
cmp dword ptr [rcx+11BCh],0
main ENDP
END
我无法构建它（我一直收到有关指令长度匹配的错误），直到我更改r8d 至 r8在第二节中。
我构建了这个 obj，并使用十六进制编辑器打开它，并能够找到两个字节字符串。但我的问题是，当我搜索应该在 flash ocx 中的第一个字节字符串时，我找不到它。它不存在，所以我无法用第二个替换它。
我做错了什么？
谢谢！
I am working with the Adobe Flash ocx by loading it into my C++ program. The ocx is supposed to be 64 bit but for some reason it has issues when I compile with the x64 platform. I have read up on this and found that it is likely that some function receives DWORD userData instead of void* userData through some structure and then casts it to an object pointer. This works ok in a 32-bit environment, but crashes in 64-bit.
The disassembly of the function calls inside the ocx that cause the crash are the following lines:
mov ecx,r8d
The first operation copies only low 32-bits from R8D to ECX (ECX is 32-bit).
cmp dword ptr [rcx+11BCh],0
The second operation accesses 64-bit register, where low 32-bits contains correct address and high 32-bits contains some junk. Leading to a crash, of course.
Solution
I have read that one possible solution is to do the following:
Create an asm file containing the following code:
nop nop nop mov ecx,r8d cmp dword ptr [rcx+11BCh],0 nop nop nop mov rcx,r8d // I've replaced ecx with rcx here cmp dword ptr [rcx+11BCh],0Build an obj file using this asm file and MASM.exe
- Open the obj file with a hex editor and locate the 90's that represent the nop
- In the Flash ocx locate the first string of bytes between the nops and replace it with the new string of bytes that comes after the nops. This will change it from 32 bit to 64 bit function calls.
Problem
I have attempted this by making the following asm file and building it with ml64.exe (I do not have masm.exe but I think that ml.exe is the new 32 bit version of it, and this code would only build with the ml64.exe, probably because of the 64-bit only operators?):
TITLE: Print String Assembly Program (test.asm)
.Code
main Proc
nop
nop
nop
mov ecx,r8d
cmp dword ptr [rcx+11BCh],0
nop
nop
nop
mov rcx,r8
cmp dword ptr [rcx+11BCh],0
main ENDP
END
I had trouble getting it to build (I kept getting errors about instruction length matching) until I changed r8d to r8 in the second section.
I got this obj to build, and opened it with a hex editor and was able to locate the two byte strings. But where my problem comes is that when I search for the first byte string that should be in the flash ocx, I cannot find it. It is not there, so I cannot replace it with the second one.
What am I doing wrong?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
创建一个包含以下代码的 asm 文件：
<前><代码>nop
不
不
mov ecx,r8d
cmp 双字指针 [rcx+11BCh],0
不
不
不
mov rcx,r8d // 我在这里用 rcx 替换了 ecx
cmp 双字指针 [rcx+11BCh],0
使用此 asm 文件和 MASM.exe 构建 obj 文件
我制作了以下 asm 文件并使用 ml64.exe 构建了它，
我得到了要构建的 obj，并使用十六进制编辑器打开它，并且能够找到两个字节字符串。我在Flash OCX中找到了第一个字节串，并将其更改为第二个。 （唯一实际的变化是琴弦中的 41 变为 49）
Create an asm file containing the following code:
Build an obj file using this asm file and MASM.exe
I made the following asm file and built it with ml64.exe
I got this obj to build, and opened it with a hex editor and was able to locate the two byte strings. I found the first byte string in the Flash OCX and changed it to the second one. (The only actual change was a 41 to a 49 in the strings)