1. Sunday算法与内存特征码搜索初探第一次接触内存特征码搜索时我完全被那些十六进制数字和问号搞懵了。直到发现Sunday算法这个神器才真正体会到什么叫秒搜的快感。简单来说Sunday算法就像是个超级眼疾手快的图书管理员能在茫茫内存书海中瞬间找到你要的那本书。传统暴力搜索就像挨个书架检查每本书而Sunday算法则聪明得多。它会先记住特征码中每个字符最后出现的位置我们称之为坏字符表当发现不匹配时不是傻傻地移动一位而是根据这个表直接跳到最可能匹配的位置。实测下来在搜索100MB内存时Sunday算法比暴力搜索快5-8倍内存越大优势越明显。在逆向工程中特征码通常是这样的一串55 8B EC 83 EC ?? 56 8B ?? 8B其中??就是通配符表示这个字节可以是任意值。这种模糊匹配能力对定位动态变化的代码特别有用比如游戏更新后函数入口地址变了但指令特征往往保持不变。2. C实现Sunday算法的核心要点2.1 预处理阶段的优化技巧Sunday算法的核心在于预处理阶段构建的跳转表。在C实现时我习惯用256大小的数组来存储每个字节的跳转距离因为一个字节的取值范围是0-255。这里有个坑要注意通配符的处理需要特殊对待。void BuildBadCharTable(const byte* pattern, int patternLen, int* badCharTable) { // 默认跳转距离是patternLen1 for(int i0; i256; i) badCharTable[i] patternLen 1; // 从右到左填充确保记录的是最右侧出现位置 for(int i0; i patternLen; i) { if(pattern[i] ! 0x3F) // 0x3F是我们的通配符标记 badCharTable[pattern[i]] patternLen - i; } }实测发现将通配符统一处理为0x3FASCII的?比用特殊值如256更高效因为CPU缓存命中率更高。在i7-10700K上测试这种优化能让搜索速度提升约15%。2.2 内存读取的批处理优化直接逐字节读取进程内存是性能杀手。我的经验是每次读取4KB-1MB的块根据系统缓存大小调整这样可以大幅减少ReadProcessMemory的调用次数。Windows内存页大小通常是4KB所以4096的倍数是个不错的选择。const DWORD BUFFER_SIZE 4096 * 16; // 64KB缓冲区 BYTE buffer[BUFFER_SIZE]; DWORD bytesRead; while(offset endOffset) { SIZE_T chunkSize min(BUFFER_SIZE, endOffset - offset); if(ReadProcessMemory(hProcess, (LPCVOID)offset, buffer, chunkSize, bytesRead)) { // 在buffer中应用Sunday算法搜索 int pos SundaySearch(buffer, bytesRead, pattern, patternLen, badCharTable); if(pos ! -1) return offset pos; } offset max(1, bytesRead - patternLen 1); // 滑动窗口 }3. 通配符的高级处理策略3.1 多级通配符优化实际项目中我发现特征码中通配符的位置会影响搜索效率。如果通配符集中在特征码尾部可以采用分段匹配策略先匹配前面的确定部分再验证后面的通配部分。这能减少约30%的比较操作。// 在SundayCmp函数中的匹配逻辑 for(int i0; ipatternLen; ) { if(pattern[i] 0x3F) { // 遇到通配符 int wildcardLen 1; while(iwildcardLen patternLen pattern[iwildcardLen] 0x3F) wildcardLen; // 跳过通配符段 textIdx wildcardLen; i wildcardLen; } else if(text[textIdx] ! pattern[i]) { break; // 不匹配 } }3.2 通配符位置缓存另一个实用技巧是记录第一个通配符的位置。因为Sunday算法依赖坏字符表而通配符之前的字符位置信息最可靠。我们可以这样修改预处理int firstWildcard patternLen; for(int i0; ipatternLen; i) { if(pattern[i] 0x3F) { firstWildcard i; break; } } // 只使用通配符前的字符构建跳转表 for(int i0; ifirstWildcard; i) { badCharTable[pattern[i]] firstWildcard - i; }4. 实战定位基址和CALL地址4.1 基址定位的偏移处理在逆向工程中经常需要通过特征码找到基址。比如某个对象指针可能存储在特征码匹配位置0x10的位置。我的工具函数是这样处理的DWORD FindBaseAddress(HANDLE hProcess, const string signature, int offset) { DWORD matchAddr AobScan(hProcess, signature); if(matchAddr -1) return -1; DWORD baseAddr; if(!ReadProcessMemory(hProcess, (LPCVOID)(matchAddr offset), baseAddr, sizeof(baseAddr), NULL)) { return -1; } return baseAddr; }注意x86和x64下指针大小不同在64位进程中要用DWORD64而不是DWORD。我踩过的坑是忘记考虑字节序某些游戏会使用自定义的内存布局这时候需要额外处理。4.2 CALL指令的相对偏移解析定位CALL指令时需要理解E8 CALL的操作码格式。在x86中CALL后面的4字节是相对偏移从下条指令开始计算。解析代码示例DWORD ResolveCallAddress(DWORD callInstAddr) { // callInstAddr是CALL指令的起始地址 DWORD relativeOffset; ReadProcessMemory(hProcess, (LPCVOID)(callInstAddr 1), relativeOffset, 4, NULL); // 下条指令地址是callInstAddr5 return callInstAddr 5 relativeOffset; }在x64中更复杂因为可能有RIP相对寻址。我曾遇到过一个案例游戏使用了混合模式的CALL指令最终不得不结合反汇编引擎来准确解析。5. 性能优化与错误处理5.1 内存权限过滤不是所有内存区域都值得搜索。通过VirtualQueryEx过滤可读可执行的内存区域能大幅提升效率MEMORY_BASIC_INFORMATION mbi; while(VirtualQueryEx(hProcess, (LPCVOID)addr, mbi, sizeof(mbi))) { if(mbi.State MEM_COMMIT (mbi.Protect PAGE_EXECUTE_READ || mbi.Protect PAGE_EXECUTE_READWRITE)) { // 只搜索可执行的内存区域 SearchRegion(hProcess, mbi.BaseAddress, mbi.RegionSize); } addr (DWORD)mbi.BaseAddress mbi.RegionSize; }5.2 多线程搜索对于超大内存范围如整个4GB地址空间可以分割区域并行搜索。但要注意每个线程使用独立的缓冲区找到匹配后及时通知其他线程终止控制线程数通常CPU核心数的2倍最佳vectorthread workers; const DWORD chunkSize 256 * 1024 * 1024; // 256MB每块 for(int i0; i4; i) { workers.emplace_back([](){ DWORD start i * chunkSize; DWORD end start chunkSize; SearchRegion(hProcess, start, end); }); }6. 实际项目中的调试技巧6.1 特征码稳定性测试写了个自动化测试工具在游戏更新后自动验证特征码有效性。发现几个规律函数开头的特征码最稳定中间含有字符串引用的位置也很稳定纯指令特征码在编译器优化不同时可能变化6.2 错误处理经验遇到过最棘手的bug是特征码匹配到错误位置最后发现是因为没有验证前后指令的上下文通配符过多导致误匹配内存区域权限变化导致读取失败现在的代码会做二次验证比如检查匹配位置是否在函数开头或者附近是否有特定指令模式。7. 扩展应用模式匹配引擎将核心算法抽象出来后我发现这套框架还能用于网络数据包特征检测文件格式识别病毒特征扫描关键改进点是支持多模式匹配这时可以用类似AC自动机的思路但基于Sunday算法的跳转表。在1000个模式的测试中比传统方法快3倍左右。内存特征码搜索就像数字世界的寻宝游戏而Sunday算法就是最趁手的金属探测器。每次优化都能带来新的性能突破这种成就感正是编程最迷人的地方。建议新手可以从简单的单进程扫描器开始逐步添加通配符、偏移解析等功能最后再考虑注入和跨进程等高阶技术。