冰楓論壇

標題: cms187.3 CRC=No-Mapping [打印本頁]

作者: 仁二 時間: 2022-3-28 01:53
標題: 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)
[ENABLE]
globalalloc(crc_org,5)
crc_org:
readmem(crc,5)
//----
globalalloc(show_buff,128,$process)
label(show_buff_ret)
show_buff:
mov rax,[qtjz]
cmp rax,0
je show_buff_ret
mov rcx,[rax+show_buff_offset]
readmem(show_buff_onoff,4)
show_buff_ret:
ret
crc:
call show_buff
[DISABLE]
crc:
readmem(crc_org,5)

複製代碼

距离上次发帖已经有一段时间了。看到KK的文章：“https://bingfong.com/thread-1832312-1-3.html”
得知BUG 并修复虽然很早以前已经确定了这个BUG 但是复现困难在KK的提示下
在朋友“EvansFix” 经过多次进出商城调试（我只是打辅助的）
确定了显示BUFF的关键call 并作出了修复 *这个不修复强迫症属实挺难受的看不到右上角BUFF
修复了换图飞游戏的问题……只需要操作开关即可

作者: 仁二 時間: 2022-3-28 01:57
本帖最後由仁二於 2022-3-28 02:22 編輯

因为游戏更新了X64位很多功能都没来得及更新
还有目前对X64的基础并不牢固或者说不熟悉有错误或者问题希望大家大胆指出
会在相应的时候做出修复。
CMS187.3 CEM：https://drive.google.com/drive/f ... kN-0ZYj?usp=sharing

作者: yxl9988 時間: 2022-3-28 02:36
感谢大佬，请问大佬有无其他的数据，求教

作者: ak1254664 時間: 2022-3-28 18:10
感謝大佬
轉更新發布一個TMS的版本

作者: liyaodong 時間: 2022-3-29 02:40
大佬好久不见，64位更新以后很多地方都不熟悉，想请教一下吸怪call
以前的32位都是push 00 push 00 push 64 ... push 07 ... call xxxxx 这个形式
但是在64位更新后很多push 都变成了 mov [rsp+xx],xx 这个形式，请问这种情况要怎么独立调用一些call,
感觉现在堆栈里的数据很难复刻..

作者: asd9988 時間: 2022-3-29 11:44

liyaodong 發表於 2022-3-29 02:40
大佬好久不见，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:41
本帖最後由仁二於 2022-3-29 22:44 編輯

liyaodong 發表於 2022-3-29 02:40
大佬好久不见，64位更新以后很多地方都不熟悉，想请教一下吸怪call
以前的32位都是push 00 push 00 push 64 ...

rsp+内容查看（进call后rsp-08）
00       08       10       18
[rsp]       rcx       rdx       r8d
20       28       30       38
r9d       [rsp+20][rsp+28][rsp+30]

call内的[rsp+28]
是
call前的[rsp+20]
--------------------------------------------
这个是我之前刚刚认识X64做的笔记但是不全对。。因为call前的20的空间用来记录保护别的暂存器的也有
调用吸怪call有点麻烦要认真分析一下他有一个的参数了不能直接丢0好像
虽然我已经调用成功了但是还没做稳定性测试我说一下大概调用
依次push 一下需要保护的暂存器
sub rsp,100//这个数值只是个例子看自己需要申请rsp的空间
mov [rsp+80],00
mov [rsp+78],00
mov [rsp+70],00
mov [rsp+68],00
mov [rsp+60],00
mov [rsp+58],#????       //技能ID
mov [rsp+50],64
mov [rsp+48],00
mov [rsp+40],00
mov eax,[人物y]
mov [rsp+38],eax
mov eax,[人物x]
mov [rsp+30],eax
mov [rsp+28],12//控怪模式
mov [rsp+20],01
lea r9,[xxxx???]       //这个可能是自己需要去分析的参数
mov r8d,01
mov edx,07
mov rcx,r14
call Move_Mob //调用吸怪call
add rsp,100//还原rsp保持堆栈平衡
依次pop出来还原

作者: liyaodong 時間: 2022-3-29 22:48

仁二發表於 2022-3-29 22:41
rsp+内容查看（进call后rsp-08）
00 08 10 18
[rsp] rcx rdx ...

感觉有点通顺了，非常感谢！！我去尝试调用一下

作者: liyaodong 時間: 2022-3-30 01:03

仁二發表於 2022-3-29 22:41
rsp+内容查看（进call后rsp-08）
00 08 10 18
[rsp] rcx rdx ...

更新一下结果：
1、hook点还是选用的32位版本吸怪一样的点位，个人认为这个点是为了拿r14的值，也下断验证了；

2、代码几乎和大佬你提供的一致，skillID 这里我选了我下断测试的职业自带的可拉怪技能，kain:63111004；

3、lea r9,[xxxx] 这里我在原技能调用call 的地址下断确定了这里应该是 lea r9,[rsp+90] (GMS的偏移，不一定一致)

但通过这样的方式调用还是会断线，推测是这三点原因中其中一个，希望大佬可以解惑。
调用call断线不知道怎么系统的debug

作者: 仁二 時間: 2022-4-16 07:52
本帖最後由仁二於 2022-4-16 07:54 編輯

liyaodong 發表於 2022-3-30 01:03
更新一下结果：
1、hook点还是选用的32位版本吸怪一样的点位，个人认为这个点是为了拿r14的值，也下断验 ...

lea r9,[xxxx???] //这个可能是自己需要去分析的参数
似乎这个参数也不是必要的随便传递一下空地址或者丢0 可能都可以
飞游戏的话rsp必须16字节对齐不然DUMP都不会出现。。
现在内存中很多mouaps这种操作[rsp/rbp+N]的在调用call前保证你的堆栈是0结尾的就行了
就是+8/-8的事举个例子你调试自己的调用点看进call前的rsp是多少比如005a688这样是8结尾 rsp多-08
保证16字节对齐

歡迎光臨冰楓論壇 (https://bingfong.com/)