加壳后在内存中解密代码节区需在加壳器入口点处执行：先用VirtualProtect将.text节内存属性改为PAGE_READWRITE，再按RVA计算实际地址并XOR解密，完成后恢复为PAGE_EXECUTE_READ，最后通过push+ret安全跳转至原始OEP。
加壳后如何在内存中解密代码节区
加壳程序运行时必须把加密的 .text 节区还原成可执行机器码，否则 CPU 无法执行。关键不是“怎么加密”，而是“在哪解密、用什么上下文解密”。常见错误是直接在 main() 里解密 —— 此时 PE 加载器早已完成重定位和 IAT 修复，原始节区可能已被标记为只读（PAGE_READONLY），写入会触发 ACCESS_VIOLATION。
正确做法是在入口点（即加壳器自己的 OEP）处、PE 基础结构就绪但尚未跳转前操作：
- 调用
VirtualProtect将目标节区（如.text）内存属性改为PAGE_READWRITE - 用对称算法（如 XOR + 密钥调度）逐块解密，注意节区实际起始地址需从
IMAGE_NT_HEADERS中解析：nt->OptionalHeader.ImageBase + section->VirtualAddress - 解密完成后立即调回
PAGE_EXECUTE_READ，避免被内存扫描工具标记为可疑
如何安全跳转到原始 OEP
原始 OEP 是加壳前程序的真正起点，比如 0x1000 这类 RVA。跳转前必须确保：导入表（IAT）已修复、重定位已完成、TLS 回调未被跳过。Windows PE 加载器在调用入口点前已做完这些，所以加壳器入口点必须模拟这个环境 —— 不能用裸 jmp 或 call 直接跳。
推荐方式是构造一个干净的栈帧并使用 ret 模拟函数返回：
立即学习“C++免费学习笔记（深入）”；
- 先保存当前栈指针（
rsp），然后将原始 OEP 的 RVA 加上模块基址得到真实地址，压入栈顶 - 执行
ret，CPU 自动弹出该地址并跳转，此时堆栈、寄存器状态与原程序启动时一致 - 切忌用
__asm jmp [addr]：VC++ 编译器可能插入栈保护或 SEH 帧，导致跳转后异常崩溃
示例片段（x64，需内联汇编或手写 shellcode）：
push qword ptr [original_oep_rva + rax] ; rax = module base ret
为什么 GetModuleHandle(NULL) 在加壳入口常返回空
加壳器入口点通常由自定义 loader 触发，而非系统 PE 加载器调用，此时 GetModuleHandle(NULL) 可能返回 NULL，因为模块未被注册进 PEB 的 Ldr 链表。这不是 bug，是加壳器绕过正常加载流程的副作用。
替代方案是手动遍历 PEB 获取模块基址：
- 从
gs:[0x60]（x64）取 PEB 地址，再读PEB_LDR_DATA中的InMemoryOrderModuleList - 遍历链表，比对每个
LDR_DATA_TABLE_ENTRY.BaseDllName或用特征字节定位自身映像 - 更简单可靠的做法：在加壳时把模块基址硬编码进 stub（如占位符
0xCCCCCCCC），打包时由加壳工具动态 patch
调试时断点失效、反调试报错的根源
加壳后代码节区解密是瞬时行为，且常伴随 VirtualProtect 权限切换。调试器（如 x64dbg）在节区为 PAGE_NOACCESS 或刚解密未设断点时，无法下硬件/软件断点 —— 表现为“断点灰色、不命中”。
绕过方法有限但实用：
- 在解密前插入
int 3（0xCC），让调试器停住，再手动修改内存权限、设置后续断点 - 禁用加壳器自身的反调试检测（如
IsDebuggerPresent、CheckRemoteDebuggerPresent）仅用于调试，发布版再开启 - 注意：某些加壳器会在解密后校验节区 CRC 或扫描
0xCC字节，强行下断点可能触发自毁逻辑
最易被忽略的一点：加壳器若使用了 TLS（Thread Local Storage）回调，而解密过程破坏了 TLS 目录结构（IMAGE_TLS_DIRECTORY），会导致程序在进入 main() 前就崩溃 —— 这类问题不会报错，只会静默退出。务必确认加壳工具是否保留并重定位 TLS 数据。
