游戏内存Call技术-易语言绑定主线程调用CALL技术(游戏反检测call)

游戏Call技术-绑定主线程调用CALL技术(反游戏检测call) 
我们在写call调用游戏进程里call时候,经常辅助运行一段时间后,游戏就会断线或崩溃掉，但是经过检查，
发现我们调用CALL的源代码又没发现写错误,这到底是怎样呢？{:100_162:}
其实这些是现在游戏的一些游戏反辅助检测导致的,并不是我们调用call的源代码没写对,
现在的游戏调用我们游戏进程里的各种CALL,都是游戏我们的主线程来执行的,如果不是游戏的主线程调用CALL,
就会奔溃或游戏掉线,

所以我们的辅助程序都是在游戏进程里创建新的线程来执行我们的源代码的,创建来线程不是游戏的主线程,
只是游戏进程里的子线程,如果游戏会对CALL调用时候检测是不是我们进程的主线程来执行的，
就会认为是非法调用CALL的辅助程序,所以就会断掉我们的网络,来阻止我们辅助操作游戏！{:100_172:}

下面为了生动点让大家了解这里面的道理,我们来设计一个模拟游戏程序.exe
模拟游戏程序.exe 的源代码如下：

里面设置一个测试方法，这个方法在被调用时候
会判断是我们进程里的主线程执行的，还是外界其他程序创建线程（非我们主线程）来执行调用的。然后做出相关提示
来真实模拟游戏以自身主线程来执行我们进程内方法的效果,
如发现不是我们进程主线程调用方法，就弹出警告（相当于游戏崩溃或掉线）
再贴上调用模拟游戏程序.exe 里面的测试方法,的调用方法.exe源代码：

调用方法.exe 就相当于我们的辅助程序,调用指定进程里的方法CALL功能,这里我演示了2种调试方式
一种是普通调用我们的源代码，一种是绑定游戏（模拟游戏程序.exe）主线程来调用我们的源代码。
好了，我们来看测试效果：

运行后,我们发现，当我们的辅助（调用方法.exe）以普通方式调用游戏（模拟游戏程序.exe）进程里的CALL时候,
游戏发现不是我们进程主线程去执行的，就弹出了警告信息框（相当于游戏自动掉线或崩溃），
而发现是我们主线程来去执行的，就正常运行！

.子程序 调用方法E, 整数型, 公开, 执行指定进程中某个方法入口,返回方法执行后的EAX值.
.参数 进程句柄, 整数型, , -1=自身进程.欲调用的方法所在进程句柄
.参数 方法地址, 整数型, ,
.参数 方法参数, 整数型, 可空 数组, 空=无参数,可以提供多参数.OD分析CALL指令往上推算,离CALL最近为参数[1].再往上是 参数[2]…
.参数 寄存器, 类型_寄存器, 可空, 可以设置各个CPU寄存器的值,注意 不支持设置 EBP,ESP,ST浮点数 这些寄存器.
.参数 绑定线程, 整数型, 可空, 提供绑定线程的线程句柄,源代码将在该线程环境执行.空=0=自进程时在现线程下执行,跨进程将创建远线程执行
.参数 取消保护, 逻辑型, 可空, 默认=假=采用SEH异常保护机制,真=不使用异常保护.若保护后CALL无效,再试试取消保护.

调用方法E
命令可以绑定目标进程里指定的线程ID，来执行我们的源代码,这样就可以有效的躲避对CALL调用的线程检测了,
但是如果游戏有Lua的话，使用时候要避免与游戏本身中的lua事件岔开调用时间,否则游戏我们主线程执行lua时候,
你再这个时候进行抢占游戏主线程去执行你的call源代码,就会导致游戏崩溃,所以每次CALL的时候,最好间隔时间调用！

如果是辅助是DLL，那么在DLL里要绑定线程执行源代码的话，可以使用 模块6.5里面的 线程_调用 （）命令即可！

最后说一句：
不是我军不够强大,只怪游戏太狡诈,以各种手段来阻止我们辅助,但是道高一尺魔高一丈,
只要知道了游戏的检测把戏.我们就有方法来对待