cms187.3 CRC=No-Mapping
本帖最後由 仁二 於 2022-3-28 13:23 編輯//cms187.3 CRC=No-Mapping
//修复进出商城后 BUFF丢失的问题
//collaborator：EvansFix
define(qtjz,1453090E0)
define(crc,141898638)
define(show_buff_offset,00002460)// (+08) 1437321FF
define(show_buff_onoff,14237E904)
globalalloc(crc_org,5)
crc_org:
readmem(crc,5)
//----
globalalloc(show_buff,128,$process)
label(show_buff_ret)
show_buff:
mov rax,
cmp rax,0
je show_buff_ret
mov rcx,
readmem(show_buff_onoff,4)
show_buff_ret:
ret
crc:
call show_buff
crc:
readmem(crc_org,5)距离上次发帖 已经有一段时间了。看到KK的文章：“https://bingfong.com/thread-1832312-1-3.html”
得知BUG 并修复 虽然很早以前已经确定了这个BUG 但是复现困难 在KK的提示下
在朋友“EvansFix” 经过多次进出商城调试 （我只是打辅助的）
确定了显示BUFF的关键call 并作出了修复 *这个不修复 强迫症属实挺难受的 看不到右上角BUFF
修复了换图飞游戏的问题……只需要操作开关即可
本帖最後由 仁二 於 2022-3-28 02:22 編輯
因为游戏更新了X64位 很多功能都没来得及更新
还有目前对X64的基础 并不牢固 或者说 不熟悉 有错误或者问题 希望大家大胆指出
会在相应的时候 做出修复。
CMS187.3 CEM：https://drive.google.com/drive/folders/1axQu3oJ0m-eZkaY7FlH5F-xQ5kN-0ZYj?usp=sharing 感谢大佬，请问大佬有无其他的数据，求教:loveliness: 感謝大佬
轉更新發布一個TMS的版本 大佬好久不见，64位更新以后很多地方都不熟悉，想请教一下吸怪call
以前的32位都是push 00 push 00 push 64 ... push 07 ... call xxxxx 这个形式
但是在64位更新后很多push 都变成了 mov ,xx 这个形式，请问这种情况要怎么独立调用一些call,
感觉现在堆栈里的数据很难复刻..
liyaodong 發表於 2022-3-29 02:40 static/image/common/back.gif
大佬好久不见，64位更新以后很多地方都不熟悉，想请教一下吸怪call
以前的32位都是push 00 push 00 push 64 ...
windows x64平台fastcall调用约定的主要特性如下：
前四个整型或指针类型参数由RCX,RDX,R8,R9依次传递，前四个浮点类型参数由XMM0,XMM1,XMM2,XMM3依次传递。
调用函数为前四个参数在调用栈上保留相应的空间，称作shadow space或spill slot。即使被调用方没有或小于4个参数，调用函数仍然保留那么多的栈空间，这有助于在某些特殊情况下简化调用约定。
除前四个参数以外的任何其他参数通过栈来传递，从右至左依次入栈。
由调用函数负责清理调用栈。
小于等于64位的整型或指针类型返回值由RAX传递。
浮点返回值由XMM0传递。
更大的返回值(比如结构体)，由调用方在栈上分配空间，并有RCX持有该空间的指针并传递给被调用函数，因此整型参数使用的寄存器依次右移一格，实际只可以利用3个寄存器，其余参数入栈。函数调用结束后，RAX返回该空间的指针。
除RCX,RDX,R8,R9以外，RAX、R10、R11、XMM4 和 XMM5也是易变化的(volatile)寄存器。
RBX, RBP, RDI, RSI, R12, R14, R14, and R15寄存器则必须在使用时进行保护。
在寄存器中，所有参数都是右对齐的。小于64位的参数并不进行高位零扩展，也就是高位是无法预测的垃圾数据。
本帖最後由 仁二 於 2022-3-29 22:44 編輯
liyaodong 發表於 2022-3-29 02:40 static/image/common/back.gif
大佬好久不见，64位更新以后很多地方都不熟悉，想请教一下吸怪call
以前的32位都是push 00 push 00 push 64 ...
rsp+内容查看（进call后rsp-08）
00 08 10 18
rcx rdx r8d
20 28 30 38
r9d
call内的
是
call前的
--------------------------------------------
这个是我之前刚刚认识X64做的笔记 但是不全对。。因为call前的20的空间用来记录保护别的暂存器的也有
调用吸怪call有点麻烦 要认真分析一下他有一个的参数了 不能直接丢0好像
虽然我已经调用成功了 但是还没做稳定性测试 我说一下大概调用
依次push 一下需要保护的暂存器
sub rsp,100//这个数值只是个例子 看自己需要申请rsp的空间
mov ,00
mov ,00
mov ,00
mov ,00
mov ,00
mov ,#???? //技能ID
mov ,64
mov ,00
mov ,00
mov eax,[人物y]
mov ,eax
mov eax,[人物x]
mov ,eax
mov ,12//控怪模式
mov ,01
lea r9, //这个可能是自己需要去分析的参数
mov r8d,01
mov edx,07
mov rcx,r14
call Move_Mob //调用吸怪call
add rsp,100//还原rsp保持堆栈平衡
依次pop出来还原
仁二 發表於 2022-3-29 22:41 static/image/common/back.gif
rsp+内容查看（进call后rsp-08）
00 08 10 18
rcx rdx ...
感觉有点通顺了，非常感谢！！我去尝试调用一下 仁二 發表於 2022-3-29 22:41 static/image/common/back.gif
rsp+内容查看（进call后rsp-08）
00 08 10 18
rcx rdx ...
更新一下结果：
1、hook点还是选用的32位版本吸怪一样的点位，个人认为这个点是为了拿r14的值，也下断验证了；
2、代码几乎和大佬你提供的一致，skillID 这里我选了我下断测试的职业自带的可拉怪技能，kain:63111004；
3、lea r9, 这里我在 原技能调用call 的地址下断确定了 这里应该是 lea r9, (GMS的偏移，不一定一致)
但通过这样的方式调用还是会断线，推测是这三点原因中其中一个，希望大佬可以解惑。
调用call断线不知道怎么系统的debug 本帖最後由 仁二 於 2022-4-16 07:54 編輯
liyaodong 發表於 2022-3-30 01:03 static/image/common/back.gif
更新一下结果：
1、hook点还是选用的32位版本吸怪一样的点位，个人认为这个点是为了拿r14的值，也下断验 ...
lea r9, //这个可能是自己需要去分析的参数
似乎这个参数也不是必要的 随便传递一下空地址或者丢0 可能都可以
飞游戏的话rsp必须16字节对齐 不然DUMP都不会出现。。
现在内存中很多mouaps这种操作的在调用call前 保证你的堆栈是0结尾的就行了
就是+8/-8的事 举个例子 你调试自己的调用点 看进call前的rsp是多少 比如005a688这样是8结尾 rsp多-08
保证16字节对齐
頁:
[1]