cms187.3 CRC=No-Mapping

仁二

1. 
   

複製代碼

1. //cms187.3 CRC=No-Mapping
   
2. //修复进出商城后 BUFF丢失的问题
   
3. //collaborator：EvansFix
   
4. define(qtjz,1453090E0)
   
5. define(crc,141898638)
   
6. define(show_buff_offset,00002460)//  (+08) 1437321FF
   
7. define(show_buff_onoff,14237E904)
   
8. [ENABLE]
   
9. globalalloc(crc_org,5)
   
10. crc_org:
    
11. readmem(crc,5)
    
12. //----
    
13. globalalloc(show_buff,128,$process)
    
14. label(show_buff_ret)
    
15. show_buff:
    
16. mov rax,[qtjz]
    
17. cmp rax,0
    
18. je show_buff_ret
    
19. mov rcx,[rax+show_buff_offset]
    
20. readmem(show_buff_onoff,4)
    
21. show_buff_ret:
    
22. ret
    
23. crc:
    
24. call show_buff
    
25. [DISABLE]
    
26. crc:
    
27. readmem(crc_org,5)

複製代碼

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

仁二

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

yxl9988

感谢大佬，请问大佬有无其他的数据，求教

ak1254664

感謝大佬  
轉更新發布一個TMS的版本

liyaodong

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

asd9988

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位的参数并不进行高位零扩展，也就是高位是无法预测的垃圾数据。

仁二

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:41
rsp+内容查看（进call后rsp-08）
00        08        10        18
[rsp]        rcx        rdx         ...

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

liyaodong

仁二 發表於 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

仁二

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字节对齐