CE实现植物大战僵尸后台运行

植物大战僵尸（汉化第一版）CE修改后台运行

windows10系统下实现植物大战僵尸后台运行。
修改的思路：游戏运行时植物冷却正常进行，游戏暂停时冷却暂停。
1. 找到卡槽冷却时间的数据地址
选择冷却时间比较长的土豆地雷，双子向日葵，和坚果进行游戏。
冷却计时器初始未知，CE中选择4字节未知数值（可能是毫秒表示）。不知道计数值是增加还是减少的话推荐都试一下。

游戏开始，搜索未知的4字节数据（许多游戏的计时器以毫秒为单位），游戏运行一段时间，查找增加的数据（也可以是减少的数据，都试一试）。

搜索到相当多的变量。让游戏进行一段时间，再次搜索增加的数据。结合数据的范围搜索（计时器数值>0，卡槽冷却时间可以求助度娘。计时单位不清楚的话，可以从毫秒尝试。搜不到的话再增大到10毫秒，20毫秒），合理使用暂停游戏，配合“未变动的数据”帮助缩小范围。
这里选择土豆地雷作为观察对象。由于一次冷却周期没有得到结果，种植之后进行了新一轮的冷却计时，按照冷却计时器增加的思路，此时的数据应该接近最小值，与上一次相比减小了。

有一个变量很符合计数器的特征，把它添加到变量列表里。把变量改成接近0的数，发现土豆雷卡片上的线条几乎就在顶部，继续游戏卡槽填装完成。这个变量就是冷却时间倒计时了呢。接下来就是寻找哪条指令写入了这个地址。

2. 寻找暂停冷却的变量。
在寻找写入冷却计时器的指令的时候，适当地暂停几次游戏。运行次数的变化规律符合暂停/继续操作的指令才是可能性更大的指令。这里只搜到唯一的指令，而且它的确在游戏暂停的时候不再执行。

打开反汇编窗口，跳转到这条指令对应的地址。设置断点，在右键弹出的选项中有一个“选择当前函数”的功能，如图所示，可以辅助分析这段代码的调用入口。
0048728C的指令为add，功能是给指定内存的数据加上一个立即数。这里内存地址的格式是edi+16进制立即数0x24，edi寄存器存放了一个地址。
如果有一定编程基础，应该了解结构体或者类的概念。它们常常用来描述具有一组特定属性和功能的事物。这里卡片槽就是一个很适合定义为结构体/类的例子，卡片至少要有植物种类、价格、冷却时间的属性。
到了这里应该做什么？我们猜测有一个关键变量，它代表游戏是否被暂停。我们要找到使用这个变量决定游戏如何运行的指令，它可能是形如cmp或test格式的比较指令，下面跟着条件跳转指令je/jne/jl/jge等（很像C语言里的if…else…，只不过使用汇编实现）。
这段程序的入口离我们找到的指令很近，可以在入口设置断点，观察分支的跳转情况。
考虑到编程的效率问题，根据一个flag决定分支的时候，通常希望只在这个flag下执行的循环全部放在分支下面。
mov edi,eax这条指令说明edi是从上层函数传进来的。如果edi是卡槽首地址，那么10个卡槽都可以使用这个函数（极有可能存在循环）。如何验证呢，如果游戏暂停，不会触发函数入口的断点，那么这段代码就一定包含在暂停变量为正在运行的分支内。

程序在断点暂停后，按快捷键F8可以逐条指令运行，一直运行到ret指令来寻找调用者。返回后在004131F4找到call指令，就是调用计时器减少函数的地方。
不出所料，调用者在一个循环内。
执行这个循环，每次esi都会加1，esi达到0A即10后退出循环，决定执行循环的是jle 0041320A指令，上接一条指令比较ebp与 [eax+24]的指令。循环退出的地方jl 004131F0比较esi和[eax+24]，格式很像。
通过设置断点可知ebp恒为0，eax+24很有可能保存游戏中的卡槽数目（一直都是0A），eax都是由mov eax,[ebx+114]设置，而且ebx在两个地方数值没有变化，说明第一条比较指令是确定卡槽数量是否<0，另一条是确定10个卡槽是否遍历完全。
找到这段程序入口并设置断点，游戏一旦暂停不再触发中断，因此这段代码仍旧不是我们要找的。
继续向上层函数搜索。

更上一层的调用者在00415948，对应的程序代码没有跳转，嗯，仍需继续回溯，虽然有些麻烦，但是不要因为繁琐就放弃。就算最后不成功也能从中学到很多东西。找到调用该段代码的地址0041601E。

在指令前面的区域有许多跳转指令，我们关心的跳转应该具有如下特点：我们关心的功能代码只会在跳转的一条分支内运行。满足条件的有两个分支，00415F70:jg 00416064，跳转地址在调用地址后面，00415DF7:je 00415E2E有一分支直接返回。
为了确定跳转过程，找到代码入口00415D40并设置断点。
令人高兴的一幕出现了，游戏暂停窗口时也发生了中断。

按F8单步执行，发现程序在00415DF7进入含有ret的长度很短的分支，跳转由cmp byte ptr [ebp+00000164],00决定。将ebp+00000164加入变量列表。
需要注意以0019开头是栈内存（esp寄存器的高16位），由于栈内变量只在一次函数调用中有效（相当于局部变量），并不是我们要找的全局变量（或者是某个函数的返回值，如果用于判断，返回值会直接放在寄存器中并使用寄存器比较指令）。此时ebp的数值为16353E88，我们可以将它加入变量列表。

3. 发现此地址对应的内存数值（指令是byte ptr，一个字节），游戏暂停变为1，游戏继续变为0
那么是不是找到正确的变量了呢？先找找写入此内存的指令（暂停/继续是否让某些指令改变了这个变量，有没有更高一级的标志变量）。

找到3条指令。
第一条在游戏继续时触发，第二条在鼠标点击窗口外部的时候触发，第三条在点击菜单暂停的时候触发。显然我们要找第二条。

按照刚才的方法分析，004502F2有一处跳转，将跳转指令改为nop空指令，游戏仍会暂停，很可惜不是要找的决定暂停的代码。不过断点只有在暂停时才会触发，可以推断此代码为暂停操作的调用函数。
此段代码更改了计时器的标志变量。从这个功能出发我们猜测一下，上次找到的变量是计时器的开关，仅仅负责卡槽这个模块，游戏的暂停/继续/点击菜单都会改变这个开关，而代表游戏暂停/继续的变量，应该负责音乐开关，暂停对话框的显示和清除，植物、僵尸动作，卡槽冷却多个行为。按这个思路继续下去，暂停/继续的变量还需要继续回溯寻找。

这段暂停的调用函数很长，看来做了很多工作。一路F8。来到上层调用的地方，可以看到注释里面标注了系统API，调用函数在User32.dll里。此API和释放鼠标有关。上面一条call edx就是刚才的子程序了。

分析此段代码，跳转很多，函数入口在0054EB80，设置断点分析。我们先看它是不是只和暂停有关。发现无论是暂停还是返回游戏（鼠标点击），即使鼠标点击的不是“回到游戏”按钮，都会断在这里。说明这里是暂停|继续的共用代码。游戏暂停后或者在游戏内点击鼠标（状态不变）就不会触发。我们找找是哪个变量决定了分支走向。

这段代码一共有4个最可能的判断变量，所幸变量都不在栈内。将用到的变量加入变量地址表：esi+4CE，esi+4CF，esi+4D2和esi+431。

不调试时候，发现esi+4CE和esi+4D2的值与窗口的焦点状态同步。窗口获得焦点时两个值同为1，窗口失去焦点时两个值同为0。推测这个函数在windows消息队列处理函数WndProc中调用，并且对应鼠标焦点事件。
鼠标窗口外点击->“失去焦点”事件处理->游戏暂停。这个过程中，只要解决任何一环就可以实现游戏不暂停。
多次调试断点寻找规律，窗口状态变化调用这段代码时，esi+4CE已经发生了变化，esi+4D2尚未变化。当这两个变量的值相反时，由al的值决定0054EBA8处的跳转，并且al的值会赋给esi+4D2。对于跳转情况，获得焦点代码分支和失去焦点代码分支没有共用部分，且执行完毕后游戏恢复运行|显示暂停提示框，因此可以肯定al为0，则游戏暂停，al为1，游戏继续。
al从何而来？分析代码可知，若esi+4CF为0，那么al的运算结果恒等于esi+4CE。而esi+4CF和esi+431的值多次运行重启未发生变化。
那么我们得出结论，esi+4CE的值很可能是当前窗口焦点状态，esi+4D2保存上一次状态。两次状态不一致，就会执行游戏暂停或恢复代码。两次状态一致，程序直接返回。
查找哪里修改了esi+4CE，确实有一个地址在窗口焦点变化时改写了它，推测这条指令属于WndProc。

在该处地址下断点，猜测游戏暂停|继续发生改变，此断点的触发会早于上一次分析的代码，确实也如此。

如果在任何情况下都不执行暂停游戏的代码，游戏就不会暂停；
一个很直接的思路就是让esi+4CE(要写入的状态值)恒为1(获得焦点)，。
那么有两种方法验证我们的猜测。
从可能位于WndProc 内修改esi+4CE的代码入手，将写入值改为常量 1。
将esi+4CE和0的cmp指令改为与1的or指令。
推荐第二种方法。因为第一种方法目标指令只有6字节，而将更改后的指令需要10个字节。第二种方法前后字节数相等。
如果游戏后台运行成功了，那么先前的分析都证明是正确的。

4. 验证
后台运行是否成功了呢？无法录制gif，只能用其他窗口遮挡截图了。（PS:不成功我还会发出来吗）

现在就是保存成果啦。
菜单栏，工具->自动汇编或者Ctrl+A快捷键。可以使用模块地址。

大功告成。

PS：知道了这段代码的用处，可以尝试多种方式实现后台运行，不仅仅是更改焦点状态变量。
另一种思路就是修改跳转了。这种方式被更多使用。修改跳转条件，修改跳转地址，都很容易实现而且修改代码量很少，在1-2个字节。
对于所有的cmp，test以及范围在几万以内的加减运算来说，jo(jump if overflow) 可以实现任何情况都不跳转，与之相反的jno(jump if not overflow) 可以实现绝对跳转，当然jmp也可以。对于6个字节的长跳转指令，修改为call指令方便执行注入代码，或者简单地把跳转指令的目的地址改为自己注入代码的位置（如果程序每次执行都有固定地址的空白内存使用）。
经典的植物大战僵尸辅助工具V3.1就是修改跳转指令实现的。

CE实现植物大战僵尸后台运行相关推荐

ce修改植物大战僵尸阳光
ce修改植物大战僵尸阳光准备: CE修改器植物大战僵尸游戏易语言选择进程,最重要的是找到阳光的基址阳光数量为50 首次扫描和再次扫描找到阳光的动态地址找出是什么改写了这个地址,并双击偏 ...
CE修改植物大战僵尸-关卡基址（小宇特详解）
CE修改植物大战僵尸-关卡基址这里是CE修改植物大战僵尸的第二个博客,其他的操作请看我之前的博客. 植物大战僵尸的关卡基址寻找. 这里说明一下版本: CE:CE7.4 植物大战僵尸版本:植物大战僵尸 ...
CE修改植物大战僵尸-天上无限掉落阳光（小宇特详解）
CE修改植物大战僵尸-天上无限掉落阳光里是CE修改植物大战僵尸的第三个博客,其他的操作请看我之前的博客. 天上无限掉落阳光. 这里说明一下版本: CE:CE6.8 植物大战僵尸版本:植物大战僵尸95 ...
[re入门]ce对植物大战僵尸的修改
CE对植物大战僵尸的修改 1.对阳光的修改思路:通过种植物来改变阳光的数值,ce中使用精确数值搜索即可,如下图植物偏移地址的寻找(不需要每次都搜阳光地址,直接修改即可) 上面的地址点右键,什么访问 ...
C语言+CE修改植物大战僵尸阳光
目录 1. CE使用 2. C语言代码 3. 效果 1. CE使用思路,通过CE找到阳光的静态基址和偏移值,也就是基址+偏移值 = 阳光数目的地址 1.打开植物大战僵尸和CE 2. 打开植物大战僵尸 ...
用od、ce实现植物大战僵尸自动收集阳光
找地址首先使用ce查看阳光的地址然后F6是什么改写了地址地址找到了,复制00430A11这个地址,在od中搜索分析打开od,file–>attach(关掉ce 才可以打开进程),找到植 ...
CE修改植物大战僵尸豌豆射手的射速
首先我们要找到吐出豆豆的地址.当一个豌豆射手吐出一个豆豆后,豆豆距离僵尸的距离会逐渐减少.这个就是我们ce扫描时的突破口.由于豆豆的速度比较快我们扫描起来不方便,这里改变游戏的速度,方便我们扫描.我们 ...
CE实现植物大战僵尸之阳光篇
阳光篇阳光基址阳光基址扫描初始值首次精确扫描50,收集一次阳光后再次搜索数值增加了,数值选择50.可以得到唯一的地址 2.右键"是什么访问了地址" 3.记下地址和偏移量,再 ...
C/C++植物大战僵尸之CE找基址+修改器制作(基础版)
思路: 每个程序打开后他们的数据的内存地址都会改变,但他们的静态基址和偏移不会变关于获取的是静态基址,所以就算是关闭了游戏,再开启动,地址也是不变的也可以修改所以我们用CE找到他的静态地址和偏移地 ...
C语言实现植物大战僵尸自动收集阳光(一) 问题分析与寻找基址
C语言实现植物大战僵尸自动收集阳光(一) 问题分析与寻找基址 C语言实现植物大战僵尸自动收集阳光(二) C语言控制台程序的实现 C语言实现植物大战僵尸自动收集阳光(三) 解决收集不全与收集奖杯卡死的问 ...

CE实现植物大战僵尸后台运行

植物大战僵尸（汉化第一版）CE修改后台运行

CE实现植物大战僵尸后台运行相关推荐

最新文章

热门文章