关于保护自己的汇编禁止被访问

li609545570

最近在研究某一款台F game
发现一个问题,问题如下
实现了某一项功能 但是会被检测
game自身主进程汇编指令是
mov [ecx+1C],eax
那么我修改EAX肯定会被检测的
于是乎我就找了一条与此功能无关的模块 线程地址
从另外的线程跳转到空地址

空地址 然后代码如下
mov ebx,[00CDEAF0] 这个地址就是上面的ECX+1C的地址
下面写入
mov [ebx+1c],1
cmp eax,0000FFFE  这里是找到的可用模块内的线程地址汇编
JMP 跳回到线程地址上

也就是说我并没有改任何game 主进程的数据
然后通过上面的代码也实现了同样的功能
但是我发现依然被检测
发现00CDEAF0 +1C 得到的地址 用CE访问地址
直接就访问到了我写在某线程地址上 的数据
所以我一直怀疑就是被访问到我的这个地址数据 而检测的
请问可有什么有效办法,让00CDEAF0 +1C 得到的地址 无法访问到 我写的mov [ebx+1c],1
除了VEH,可还有其他禁止让00CDEAF0 +1C 得到的地址 访问我自己写的自定义的地址数据！

LLXXLL

li609545570 发表于 2025-7-16 10:37
还没达到那个高度,哈哈哈！

CE直接附加看看是什么访问这段代码然后进去分析看看那个是对这段代码做检测的直接返回或者nop

尛龍科技

不能直接HOOK一个合法的地址进行替换吗

appleqc

在游戏逆向中，保护自定义汇编代码不被检测的核心是**隐藏内存修改痕迹**和**隔离访问路径**。针对你的场景（修改`[00CDEAF0 + 0x1C]`的值被检测），除了VEH（异常处理），以下是几种更隐蔽的解决方案，从用户态到轻量驱动级思路均有覆盖：


### 一、内存Hook反向拦截（用户态首选）
核心思路：**Hook游戏中访问`00CDEAF0 + 0x1C`的指令**，当游戏读取该地址时返回原始值，仅在实际功能逻辑中使用修改后的值，让检测机制“看”不到修改。

#### 实现步骤：
1. **定位访问点**：  
   用CE的“找出是什么访问了这个地址”功能，记录所有读取`00CDEAF0 + 0x1C`的汇编指令（例如`mov eax, [00CDEAF0 + 0x1C]`）。

2. **Hook这些读取指令**：  
   用`Detours`或`MinHook`等库，对访问该地址的指令进行Hook，在Hook函数中判断访问来源：  
   - 若来自游戏检测模块（如特定线程/函数），返回原始值（未修改前的值）。  
   - 若来自正常功能逻辑，返回修改后的值（即你设置的`1`）。

3. **示例汇编伪代码**（Hook后的处理逻辑）：
   ```asm
   ; 原始指令：mov eax, [00CDEAF0 + 0x1C]
   ; Hook后的代理函数
   Hook_Proxy:
       pushad
       ; 判断当前访问是否来自检测线程
       mov eax, [GetCurrentThreadId]
       cmp eax, 检测线程ID
       je  返回原始值
      
       ; 正常逻辑：返回修改后的值
       mov eax, 1
       popad
       jmp 原始指令后地址
      
   返回原始值:
       mov eax, [原始值存储地址]  ; 提前保存的未修改值
       popad
       jmp 原始指令后地址
   ```


### 二、内存虚拟化（隔离修改痕迹）
核心思路：**不直接修改目标地址，而是通过“虚拟内存层”代理访问**，游戏访问的是“虚拟地址”（原始值），你的功能代码访问的是“实际地址”（修改后的值），两者通过映射隔离。

#### 实现方式：
1. **创建影子内存**：  
   分配一块与`00CDEAF0 + 0x1C`所在内存页大小相同的“影子内存”，复制原始内存数据到影子内存。

2. **修改页表映射**：  
   通过`VirtualProtectEx`或驱动级API（如`MmMapIoSpace`），将游戏进程对`00CDEAF0 + 0x1C`的访问映射到影子内存（原始值），而你的自定义线程访问时映射到实际修改后的内存。  
   - 优点：彻底隔离，游戏检测到的始终是原始值。  
   - 缺点：需要处理内存页属性（可读/可写），用户态实现可能受权限限制，驱动级更稳定。


### 三、原子操作+时机欺骗（减少暴露窗口）
核心思路：**仅在必要时修改目标地址，完成功能后立即恢复原始值**，利用时间差躲避检测（假设检测是周期性的，而非实时）。

#### 实现步骤：
1. **记录原始值**：  
   先读取`00CDEAF0 + 0x1C`的原始值（如`old_val`）并保存。

2. **功能触发时临时修改**：  
   在你的功能需要生效的瞬间（如按下技能、触发事件时），用原子操作（`InterlockedExchange`）快速修改为`1`，执行功能后立即改回`old_val`。  
   ```c
   // C伪代码
   void 触发功能() {
       DWORD old_val = *(DWORD*)(0x00CDEAF0 + 0x1C);  // 读原始值
       InterlockedExchange((LONG*)(0x00CDEAF0 + 0x1C), 1);  // 临时修改
       执行功能逻辑();  // 快速完成
       InterlockedExchange((LONG*)(0x00CDEAF0 + 0x1C), old_val);  // 立即恢复
   }
   ```

3. **适配检测周期**：  
   通过CE观察游戏检测`00CDEAF0 + 0x1C`的频率（如每100ms一次），确保修改→恢复的时间窗口小于检测周期（如控制在50ms内），降低被捕获的概率。


### 四、线程隐藏与内存标记（躲避枚举）
如果游戏通过枚举线程或内存页属性检测异常，可补充以下措施：

1. **隐藏自定义线程**：  
   - 用`NtSetInformationThread`设置线程隐藏标志（`ThreadHideFromDebugger`），避免被游戏枚举到异常线程。  
   - 线程入口点伪装成系统模块函数（如`kernel32.dll`中的函数），降低可疑度。

2. **清理内存页属性**：  
   自定义代码所在的内存页，用`VirtualProtect`将属性从`PAGE_EXECUTE_READWRITE`改为`PAGE_EXECUTE_READ`（执行后改回），避免被检测到“可写可执行”的异常内存页。


### 五、驱动级保护（终极方案）
如果用户态方法仍被检测，可考虑轻量驱动（需签名，适合非反作弊严格的游戏）：

1. **内存重定向**：通过驱动拦截内存访问请求（`MmCopyVirtualMemory`），对`00CDEAF0 + 0x1C`的读取请求返回原始值，写入请求仅在自定义逻辑中生效。  
2. **隐藏内存痕迹**：驱动级可直接操作页表，让游戏进程的页表项指向原始内存，而自定义代码通过物理地址直接访问修改后的值，完全绕过用户态内存映射。


### 总结推荐方案
- **优先尝试**：内存Hook反向拦截（实现简单，用户态即可完成，适合大部分场景）。  
- **次选方案**：原子操作+时机控制（无需复杂Hook，适合检测频率较低的游戏）。  
- **终极方案**：驱动级内存重定向（对抗强反作弊，需驱动开发基础）。

核心逻辑是**让“检测路径”看到原始值，“功能路径”使用修改值**，从根本上隔离检测与功能的内存访问，避免直接修改被“抓包”。

ganyilu

那你用硬断HOOK啊，你这明显是CRC啊。

li609545570

ganyilu 发表于 2025-7-15 20:35
那你用硬断HOOK啊，你这明显是CRC啊。

硬段HOOK不是要注入DLL后,此game还检测注入后的DLL  内存注入都没用
所以我不修改主进程数据 单独找了条DLL函数的线程写的！
但是游戏似乎依然可用通过地址+偏移的访问来源检测到

li609545570

尛龍科技 发表于 2025-7-15 19:29
不能直接HOOK一个合法的地址进行替换吗

HOOK不得注入DLL吗
此台F 检测注入后的DLL 内存注入什么的都不行
所以我才不动主进程任何数据
直接在DLL模块的函数里 找到一条可用线程
然后通过此条线程 执行我的数据
功能是在不动主进程数据的情况下实现了
但是似乎发现  比如DLL模块地址是65FD0000
我把数据写在这个模块里
游戏依然可通过地址+1C的的地址 访问来源能检测到
我在65FD0000写入了什么
所以我判断此game 应该是加入了VEH异常处理！
访问到非游戏主进程的来源地址时 就确定是第三方了！

ganyilu

你自己成功把自己搞混乱了。
我得自己代入自己曾经瞎搞的那种阶段，才能稍微明白你心里所想。
你现在就是那种不明所以的阶段，胡乱瞎搞。

我问你，你是不是先直接改那个动态地址上的数据，改为1，被检测了。
然后以为或者说希望通过其他方式修改，就不会被检测。

LLXXLL

远程读写也可以无痕hook不过我没有写过，知道是crc为啥不直接做掉检测？

li609545570

ganyilu 发表于 2025-7-15 22:46
你自己成功把自己搞混乱了。
我得自己代入自己曾经瞎搞的那种阶段，才能稍微明白你心里所想。
你现在就是那 ...

是的,因为此game 无驱动检测！
主进程内存是有CRC检测的
而且HOOK了读写函数
重点是我没在主进程内存内写数据
而且写在了DLL模块上
例如 ntdll  写在game加载的DLL模块上了
所以依然会被检测
我用CE访问来源 看到地址+1C  可访问到我在DLL模块上修改的地址和汇编
所以我才判定是不是游戏挂了VEH 监控了地址+1C的访问来源 是否来自game主进程的地址访问的
如果不是 就是第三方！