Lua模块-使用WriteProcessMemory函数时出错，类型不确定(unit32)

Question

require "alien"

--the address im trying to edit in the Mahjong game on Win7
local SCOREREF = 0x0744D554 
--this should give me full access to the process
local ACCESS = 0x001F0FFF
--this is my process ID for my open window of Mahjong
local PID = 1136

--function to open proc
local op = alien.Kernel32.OpenProcess
op:types{ ret = "pointer", abi = "stdcall"; "int", "int", "int"}

--function to write to proc mem
local wm = alien.Kernel32.WriteProcessMemory
wm:types{ ret = "long", abi = "stdcall"; "pointer", "pointer", "pointer", "long", "pointer" }


local pRef = op(ACCESS, true, PID)
local buf = alien.buffer("99")

--         ptr,uint32,byte arr (no idea what to make this),int, ptr
print( wm( pRef, SCOREREF, buf, 4, nil))
--prints 1 if success, 0 if failed

这就是我的密码。我甚至不确定是否正确设置了类型。

我完全迷路了，需要一些指导。我真希望有更多的外星人的在线帮助/文档，这让我可怜的大脑感到困惑。

完全令我困惑的是，WriteProcessMemory有时会成功地完成(尽管据我所知，它什么也不做)，有时也无法成功地完成。就像我说过的，我的大脑很痛。

任何帮助都很感激。

Answer 1

看起来缓冲区只包含2个字节("99")，但是在调用WriteProcessMemory时指定了4个字节。

如果您的目的是将32位值99写入内存(作为数字，而不是ASCII字符串)，则可以使用：

alien.buffer("\99\0\0\0")

可以使用alien.struct.pack将任意整数转换为字符串表示形式。

require "alien.struct"
s = alien.struct.pack('i', 99)
buf = alien.buffer(s)

Answer 2

我知道这个问题早就被人遗忘了，但我遇到了同样的问题(具有相同的功能)，网络上除了这个问题什么也没有，然后我自己解决了，所以我把我的解决方案留在这里。

短答案

WriteProcessMemory的第二个参数的类型不是“指针”。我的意思是，从官方的角度来看，但是外星人不能把一个原始地址投到“指针”，所以你最好假装它是“长”。所以您的类型声明应该看起来像

wm:types{ ret = "long", abi = "stdcall"; "pointer", "long", "pointer", "long", "pointer" }

长答案

我在玩ReadProcessMemory，因为我觉得在写东西之前，你需要验证这个东西是否真的存在。所以有一次我打电话给ReadProcessMemory，它返回了一个缓冲区，这不是我想要的，但它也不是空的。事实上，它似乎是写在那里的--就像ASCII字符串一样。不过，不是短信，只是一些数字。但这足以让我相信这些数据实际上来自某个地方。

所以我抓起了欺骗引擎，打开了相同的进程，并搜索了这个字符串。你猜怎么着-它确实在那里，但地址完全错了。这让我相信地址写错了。在试图找到从Lua数字生成“指针”对象的方法之后，我放弃并更改了类型声明--毕竟，指针只是一个不同解释的整数。

在这之后，我做了一些调查，包括阅读lua和外星的来源，并使用调试器来完成相关的部分。事实证明，错误的完整演练如下：

“指针”关键字对字符串具有特殊的行为:如果“指针”-declared参数实际上是Lua字符串，则会立即创建一个新缓冲区，将字符串复制到其中，并将其用作真实的this

• lua_isstring函数，不仅对实际字符串，而且对数字也是"true“，因为它们是自动转换为字符串的。因此，SCOREREF被转换为字符串，复制到新创建的缓冲区中，由于大多数进程在其各自的地址空间中的布局是相似的，因此这个空地址*常常与目标进程中的某个或另一个事物的地址相吻合。这就是为什么系统调用有时会接踵而至的原因，它只是写到一个完全错误的地方。