暴力匹配易因越界读、内存区域过滤不当或位数混用导致漏匹配；kmp需适配字节流特性，避免字符串假设，通配符场景须降级为暴力+位掩码。
暴力匹配在小数据量下够用，但扫描整个进程内存时容易卡死或漏匹配；KMP 能避免回退，但必须正确处理字节序列的边界与不完整模式。
暴力匹配：为什么 memcmp 容易漏掉跨页/跨段的匹配
直接对每字节起始位置调用 memcmp 看似简单，但实际中常因以下原因失败：
- 目标模式长度为 8 字节，而扫描到内存末尾只剩 3 字节时，
memcmp会越界读 —— 触发访问违规或静默返回假阴性 - Windows 下用
VirtualQueryEx获取内存区域后，若未跳过MEM_FREE或MEM_RESERVE区域，ReadProcessMemory会失败，但循环仍继续，导致大量无效重试 - 未考虑目标进程是 32 位而当前工具是 64 位（或反之），
SIZE_T与DWORD混用造成地址截断
实操建议：先用 VirtualQueryEx 过滤出 MEM_COMMIT | PAGE_READABLE 的块，再对每块做「剩余长度 ≥ 模式长度」的预判，最后用 ReadProcessMemory 一次性读入缓冲区，本地 memcmp。
KMP 预处理：字节数组不能直接套用字符串 KMP
标准 KMP 的 next 数组依赖字符可比较且有明确「相等」语义，而内存搜索中：
- 字节是
uint8_t，无大小写、无编码层，但存在全零、重复高字节等特殊 pattern，需用std::vector<uint8_t></uint8_t>存储而非std::string（后者可能误截断\0） -
next[0] = -1是常见写法，但用于字节流时，索引偏移易错 —— 建议统一用int下标，且构建时用pattern[i] == pattern[len]判断，不依赖任何 string 成员函数 - 若模式含通配符（如
??表示任意字节），KMP 不适用，必须降级为暴力 + 位掩码匹配
简短示例（KMP 构建）：
std::vector<int> build_next(const std::vector<uint8_t>& pattern) {
int len = 0;
std::vector<int> next(pattern.size(), 0);
for (int i = 1; i <h3>跨平台读取：Linux 的 <code>/proc/pid/mem</code> 与 Windows 的 <code>ReadProcessMemory</code> 关键差异</h3>
<p>两者权限模型和错误反馈完全不同，不能共用一套异常逻辑：</p>
<ul>
<li>Linux 下打开 <code>/proc/pid/mem</code> 需 <code>ptrace(PTRACE_ATTACH)</code> 权限，否则 <code>open()</code> 直接失败；而 Windows 中 <code>OpenProcess(PROCESS_VM_READ)</code> 失败后，还需检查是否缺少 <code>SeDebugPrivilege</code>
</li>
<li>Linux 读取时若遇不可读页，<code>read()</code> 返回 -1 并设 <code>errno = EIO</code>；Windows 中 <code>ReadProcessMemory</code> 返回 <code>FALSE</code>，必须调 <code>GetLastError()</code> 判定是 <code>ERROR_PARTIAL_COPY</code> 还是 <code>ERROR_ACCESS_DENIED</code>
</li>
<li>Linux 下需按 <code>getpagesize()</code> 对齐读取起点，否则部分页可能被跳过；Windows 中地址无需对齐，但跨页读取仍要分两次 <code>ReadProcessMemory</code> 调用（系统不保证单次调用跨越保护边界）</li>
</ul>
<p>实操建议：封装统一接口 <code>bool read_memory(HANDLE hProc, uintptr_t addr, void* buf, size_t len)</code>，内部按平台分支处理错误与重试逻辑，上层只管调用。</p>
<h3>真实场景下的性能陷阱：为什么多线程扫内存反而更慢</h3>
<p>看似把内存分块丢给多个线程能加速，但实践中往往适得其反：</p>
<ul>
<li>频繁调用 <code>ReadProcessMemory</code> 或 <code>read()</code> 是系统调用，上下文切换开销远高于 CPU 匹配 —— 单线程批读 + 内存内 KMP 反而更快</li>
<li>若用 <code>std::async</code> 启动数十个线程扫不同区域，Windows 下 <code>ReadProcessMemory</code> 会争抢同一个内核对象锁，出现明显排队等待</li>
<li>没有预分配读缓冲区，每个线程临时 <code>new</code> 几 MB 内存，触发频繁堆分配与 TLB miss</li>
</ul>
<p>真正有效的优化是：单线程顺序读取大块（如 1MB），用 <code>mmap</code>（Linux）或 <code>CreateFileMapping</code>（Windows）做零拷贝映射，再对映射区跑 KMP；匹配到后记录虚拟地址，不立即读后续内容。</p>
<p>最易被忽略的一点：内存搜索结果里的地址是目标进程的 VA，不是你进程的；直接解引用会崩。所有匹配到的地址，必须再走一遍 <code>ReadProcessMemory</code>（或 <code>read</code>）才能拿到真实值 —— 这步不能省，也不能靠“大概率可读”跳过校验。</p></int></uint8_t></int>C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
