高级反逆向技术实战指南加壳脱壳、代码虚拟化与反反汇编深度解析GitHub Trending agents 仓库 anti-reversing-techniques 技能参考【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本篇技术指南以 GitHub Trending agents 仓库中reverse-engineering插件的anti-reversing-techniques技能高级参考文档为骨架系统讲解逆向分析中最具挑战性的五类进阶防护技术加壳与加密、基于虚拟机的代码保护VMProtect/Themida 类、高级反反汇编技巧重叠指令与自修改代码、基于 CPU 指令侧信道的虚拟机检测以及基于 PE 结构与熵分析的加壳识别。读者读完将掌握一套可直接落地的分析工作流——从识别加壳器、ESP 脱壳、OEP 定位、IAT 修复到 VM 入口定位、handler 表映射、IR 提升再到 RDTSC/CPUID/IN 指令层面的 VM 指纹判定并能在 malware-analyst.md、reverse-engineer.md 等技能与 Agent 的配合下完成受保护二进制的授权分析。文档定位反逆向技能体系中的高级参考层在仓库的技能组织方式中anti-reversing-techniques遵循「渐进式披露progressive disclosure」设计主文件 SKILL.md 只保留高频通用模式API 反调试、PEB 检测、控制流平坦化、字符串加密等而把面向深度分析的进阶内容下沉到references/目录。从源码结构看该技能的引用链清晰可循references/details.md 承载反调试、反 VM、代码混淆的详细模式与绕过方案references/advanced-techniques.md即本文主题文档专门收录虚拟化保护、加壳器内部原理、反反汇编技巧这三类「小众但硬核」的内容SKILL.md 中以[references/advanced-techniques.md](https://link.gitcode.com/i/94a1dd3fd19f936d3868cf0a0da67cd6)和[references/details.md](https://link.gitcode.com/i/0fd8e25e774a60141acc0896add3f5cf)两处显式链接完成分层导航。这一「主文档 引用层」的拆分机制与仓库的工具链实现相互印证在 tools/adapters/codex.py 中可以看到Codex 适配器对SKILL.md正文有约 8 KB 的上限约束超限内容会被路由到references/details.md或references/_overflow.mdtools/adapters/base.py 则在镜像技能时会自动复制references/、assets/、scripts/等支持文件。因此advanced-techniques.md这类引用文档不仅是给人看的分析笔记也是多 harnessClaude Code、Codex、Cursor 等安装技能时的实际组成部分——这正是本仓库「Multi-harness agentic plugin marketplace」定位在技能层的具体体现。需要特别说明的是整个技能体系在 SKILL.md 开头即声明了AUTHORIZED USE ONLY授权边界任何绕过或分析行为都必须先确认拥有软件所有者的书面授权或处于合法安全上下文CTF、授权渗透测试、恶意软件分析、学术安全研究并了解未经授权绕过软件保护可能违反 CFAA、DMCA anti-circumvention 等法律。本文所有内容均服务于上述合法分析场景。加壳与加密Packing and Encryption加壳Packing是保护者对抗静态分析的第一道防线可执行文件在磁盘上以压缩/加密形式存在运行时由一段「壳代码stub」在内存中还原真实代码后跳转执行。掌握常见加壳器特征与脱壳方法论是后续所有动态分析的前提。常见加壳器Common Packers参考文档给出的加壳器速查表涵盖了开源、商业与恶意软件常用三类UPX - Open source, easy to unpack (upx -d) Themida - Commercial, VM-based protection with anti-debug VMProtect - Commercial, code virtualization with multiple VM architectures ASPack - Compression packer, LZSS-based PECompact - Compression packer with CRC integrity checks Enigma - Commercial protector with key-based licensing MPRESS - LZMA-based packer, often used by malware Obsidium - Commercial, anti-debug anti-VM encryption分析时可以依据两条主线记忆这张表压缩类 vs 虚拟化类UPX、ASPack、MPRESS 属于「压缩壳」内存中还原后的代码仍是原生指令静态反汇编可恢复Themida、VMProtect、Enigma、Obsidium 属于「保护类」叠加了反调试、反 VM、代码虚拟化或密钥授权校验脱壳后往往仍需处理第二层虚拟化保护恶意软件倾向MPRESSLZMA 压缩与 UPX 修改版因免杀容易、上手门槛低在恶意样本中出现频率高商业保护器则更多出现在正版商业软件与破解对抗场景。脱壳方法论Unpacking Methodology参考文档给出了从识别到修复的完整流程1. Identify packer (DIE, Exeinfo PE, PEiD, detect-it-easy) 2. Static unpacking (if known packer): - UPX: upx -d packed.exe - Use existing unpacker tools from UnpacMe, MalwareBazaar 3. Dynamic unpacking: a. Find Original Entry Point (OEP) b. Set breakpoint on OEP c. Dump memory when OEP reached d. Fix import table (Scylla, ImpREC) 4. OEP finding techniques: - Hardware breakpoint on stack (ESP trick) - Break on common API calls (GetCommandLineA, GetModuleHandle) - Trace and look for typical entry prologue (push ebp / mov ebp, esp) - Check for tail jump pattern: jmp far address其中「静态优先、动态兜底」是核心思路已知加壳器尤其是 UPX应优先尝试工具一键脱壳避免不必要的动态分析开销只有未知壳或修改壳才需要走「找 OEP → 下断点 → dump → 修 IAT」的动态路线。OEP 定位的四种手法中ESP 技巧对绝大多数压缩壳一打一个准而tail jump尾部远跳是压缩壳还原完毕、即将跳回原始代码的典型标志。手动脱壳ESP 技巧x64dbg 实战对于无法静态脱壳的样本参考文档给出了 x64dbg 下的标准 ESP 脱壳步骤1. Load packed binary in x64dbg 2. Note entry point (packer stub address) 3. Use ESP trick: a. Run to entry point (F9 then F8 until PUSHAD) b. Right-click ESP value → Follow in Dump c. Set hardware breakpoint on access (HW BP on [ESP]) d. Run (F9) — execution breaks after POPAD (stack restored) 4. Look for JMP to OEP (often a far jump to .text section) 5. At OEP, use Scylla plugin: - IAT Autosearch → Get Imports - Dump process - Fix dump with importsESP 技巧的原理多数压缩壳的入口代码以PUSHAD压入所有通用寄存器开始以POPAD结束。由于PUSHAD会把寄存器现场写入栈壳解压期间这个栈区域不再被访问当POPAD执行、栈恢复到原始状态时必然触发对该栈地址的访问。因此在PUSHAD之后对[ESP]设置硬件访问断点不产生 INT3 修改能规避壳的反调试检测运行后即可在POPAD处断下——此时壳代码已解压完毕紧随其后的远跳通常跳向.text节就是 OEP。断到 OEP 后还需完成收尾两步dump 内存抓取已还原的映像与修复导入表IAT Autosearch → Get Imports → Fix dump。Scylla 的 IAT 自动搜索对多数壳有效若修复后程序仍无法运行说明壳对 IAT 做了更复杂的动态解析需要回到第 3 步结合 API 断点GetCommandLineA、GetModuleHandle重新定位。这与 reverse-engineer.md 中「Phase 1: Reconnaissance → Phase 3: Dynamic Analysis」的方法论完全对齐——先做加壳器识别Packer detection再进入断点策略与执行追踪。UPX 变种脱壳与魔数修复UPX 因开源且upx -d可一键还原攻击者常修改其头部特征绕过工具检测。参考文档给出的处理路线# Standard UPX — direct decompress upx -d packed.exe -o unpacked.exe # Modified UPX header (signature patched to evade upx -d): # 1. Find UPX0/UPX1 section names (may be renamed) # 2. Restore original UPX magic bytes: 0x55 0x50 0x58 # 3. Then run upx -d # Python: restore UPX magic for patched header python3 -c import sys data open(sys.argv[1], rb).read() # UPX magic at various offsets — search for stub pattern idx data.find(b\x60\xBE) # PUSHAD; MOV ESI stub print(fStub at: {hex(idx)}) 要点拆解UPX 魔数0x55 0x50 0x58即 ASCII UPX是upx -d判断文件是否可解压的依据篡改后工具会直接拒绝处理节名UPX0/UPX1是另一识别特征修改版常改名为普通节名Python 脚本中的\x60\xBEPUSHAD; MOV ESI, ...是 UPX 壳入口的典型 stub 字节序列用于在节名与魔数都被改写时仍然定位壳代码位置从而手工恢复特征。从源码结构看这类「识别被混淆的加壳样本」能力正是 malware-analyst.md 与 firmware-analyst.md 在恶意样本与固件分析场景中的基础技能可配合 binary-analysis-patterns 技能的静态分析工作流使用。基于虚拟化的保护Virtualization-Based Protection代码虚拟化是商业保护器VMProtect、Themida的核心手段它把原始 x86 代码转换成自定义字节码由嵌入二进制的解释器虚拟机在运行时逐条解码执行。这是当前对抗静态分析最强的技术之一也是本参考文档的重头戏。代码虚拟化架构参考文档用一段极简对照说明了转换本质Original x86 code is converted to custom bytecode interpreted by an embedded virtual machine at runtime. Original: VM Protected: mov eax, 1 → push vm_context_ptr add eax, 2 call vm_entry ret ; VM dispatcher loop decodes bytecode ; and invokes handler table entries ; equivalent semantics, unrecognizable form注意右侧关键点原始的三条指令被替换为「压入 VM 上下文指针 → 调用 VM 入口」两个动作实际语义计算发生在vm_entry内部的**取指-分发循环dispatcher loop**中。对静态分析者而言看到的只是一张大函数和一张 handler 函数指针表原始逻辑被彻底抹平。VM 组件识别要反虚拟化先要能在一堆混淆代码中认出 VM 的四个组成部件。参考文档给出了精确定位指引1. VM Entry Point: - Usually a CALL or JMP to a large function with a loop - Look for: load bytecode ptr, load handler table, dispatch loop 2. Handler Table: - Array of function pointers (one per virtual opcode) - Indexed by decoded opcode byte/word - Each handler emulates one instruction 3. Virtual Registers: - Stored in a context structure (vm_context) - Usually on the stack or in a dedicated heap allocation - Map to native registers by handler logic 4. Bytecode Location: - Separate section (.vmp0, .vmp1 in VMProtect) - Or inline with code (Themida) - Encrypted or compressed in some implementations识别要点可概括为「一大两表一循环」一个巨大的入口函数内含循环结构、一张 handler 函数指针表按虚拟操作码索引、一个虚拟寄存器上下文结构体vm_context通常位于栈或独立堆分配以及一个取指分发循环。字节码的存放位置因保护器而异——VMProtect 使用独立节.vmp0/.vmp1可能被改名Themida 则常内联在代码中且部分实现会对字节码再做加密或压缩。反虚拟化分析工作流Devirtualization参考文档给出的五步工作流是目前社区主流路线的浓缩1. Identify VM entry: look for large functions with indirect dispatch (jmp [regoffset]) 2. Trace execution with logging: - Use x64dbg trace log: log handler address and context on each iteration - Example trace command in x64dbg: log {p:rax} {p:rbx} (on handler dispatch) 3. Map bytecode to operations: - Each handler maps to a semantic operation (ADD, LOAD, STORE, JCC, etc.) - Build a table: vm_opcode → native semantic 4. Lift to IR: - Tools: VMAttack (IDA plugin), SATURN, NoVmp (open source, VMProtect 3) - angr: load binary, explore VM entry to extract symbolic semantics - Triton: dynamic symbolic execution to lift VM handlers 5. Reconstruct control flow: - After lifting, rebuild CFG from recovered semantics - Tools output pseudo-C or assembly that is analyzable in IDA/Ghidra逐步解读识别入口VM 分发循环的特征是指令jmp [regoffset]间接跳转目标由操作码算出这类「大函数 间接分发」模式与普通代码结构差异显著执行追踪用 x64dbg 的 trace log 在每次 handler 分发处记录寄存器与上下文示例命令log {p:rax} {p:rbx}积累执行轨迹这一步也可改用 reverse-engineer.md 中列举的 Frida、Intel Pin、DynamoRIO 等插桩工具完成语义映射每个 handler 对应一个语义操作ADD/LOAD/STORE/JCC 等逐条建立vm_opcode → 原生语义对照表这是整个反虚拟化的关键人工步骤提升到中间表示IR借助符号执行与专用工具——VMAttackIDA 插件、SATURN多壳/多 VM 类型、NoVmp开源针对 VMProtect 3或用 angr 探索 VM 入口提取符号语义、Triton 做动态符号执行来提升 handler重建控制流IR 提升完成后从恢复出的语义重建 CFG工具输出可在 IDA/Ghidra 中继续分析的伪 C 或汇编。这一工作流与 details.md 中「Code Obfuscation」章节的破解思路一脉相承——无论是控制流平坦化还是代码虚拟化最终都要落到「识别状态变量 → 映射状态迁移 → 重建原始流程」这一范式上差异只在于分析对象从普通指令变成了 VM 字节码。VMProtect 专项笔记参考文档针对 VMProtect 3.x 给出了专门观察点VMProtect 3.x uses multiple VM architectures in one binary. Each protected function may use a different VM instance. Indicators: - Sections named .vmp0, .vmp1 (or renamed) - Characteristic dispatcher: movzx eax, byte ptr [esi]; jmp [eax*4handler_table] - Functions begin with PUSH of a magic constant, then JMP vm_entry Tools: - NoVmp: open-source devirtualizer for VMProtect 3 - SATURN: IDA plugin, handles multiple packer/VM types - vmp_dumper: extracts bytecode for offline analysis最重要的认知是VMProtect 3.x 一个二进制内可能同时存在多套 VM 架构每个受保护函数都可能使用不同的 VM 实例。这意味着「搞定一个 handler 表」并不代表整个二进制都已解开——需要为每个 VM 实例分别做语义映射。识别特征包括.vmp0/.vmp1节名可能被改名、特征分发器movzx eax, byte ptr [esi]; jmp [eax*4handler_table]、以及「PUSH 魔术常量后 JMP vm_entry」的函数开头模式。工具侧 NoVmp 与 SATURN 均可尝试vmp_dumper则用于把字节码抽取出来做离线分析。高级反反汇编技巧Advanced Anti-Disassembly Tricks反反汇编anti-disassembly的目标是让线性反汇编器linear disassembly产出的指令流与真实执行路径不一致从而拖慢人工逆向。参考文档收录了四类代表性技巧。重叠指令Overlapping Instructions核心思想反汇编器解码的是一条路径CPU 实际执行的却是另一条路径——跳转目标落在一条多字节指令的中间; The disassembler decodes one path, but execution takes another. ; Jump lands in the middle of a multi-byte instruction. eb 01 ; JMP 1 (jumps over next byte) e8 ; This byte is the fake start of CALL — never executed 58 ; POP EAX — this is what executes after the JMP ; Result: linear disassembly shows CALL (e8 58 ...), but at runtime ; execution reaches POP EAX at the byte after JMP target.逐字节分析EB 01是「跳转 1」越过下一字节E8落到58。线性反汇编器从E8开始解码时会把E8 58组合成一条 CALL 指令但运行时E8永远不会执行真正执行的是POP EAX。对付重叠指令的标准手段是**递归下降反汇编recursive descent**或动态调试——按真实控制流而非线性地址推进解码。垃圾字节插入Junk Byte Insertion与重叠指令原理相近但手法更工程化插入一些「作为多字节编码的一部分看起来合法、但永远不会执行」的字节; Insert bytes that are valid as part of a multi-byte encoding ; but never actually execute (jumped over). jmp short real_code ; eb 03 — jump over 3 bytes db 0xFF, 0x15, 0x00 ; Fake MOV/CALL prefix bytes — confuse disassembler real_code: mov eax, 1 ; Actual instructionEB 03跳过 3 字节FF 15 00 ...会被线性反汇编器误读为CALL [disp32]之类的合法指令前缀从而在反汇编输出中制造一条并不存在的调用。这类垃圾字节与 details.md 中「Instruction-Level Obfuscation」的死代码插入Dead code insertion如push ebx / mov eax, 1 / pop ebx / xor ecx, ecx配合使用可以成倍污染反汇编视图。自修改代码模式Self-Modifying Code运行时先解密指令字节再执行让静态分析看到的永远是密文// Decrypt instruction bytes at runtime unsigned char code[] { 0x90 ^ 0xAA, 0xC3 ^ 0xAA }; // Encrypted NOP; RET void decrypt_and_run(unsigned char *buf, size_t len, unsigned char key) { // Mark page executable VirtualProtect(buf, len, PAGE_EXECUTE_READWRITE, old); for (size_t i 0; i len; i) buf[i] ^ key; ((void(*)())buf)(); }Analysis Approach:Set memory write breakpoints on the code region to catch decryptionUse PIN or DynamoRIO to log executed instruction addressesDump memory after self-modification to capture the real code示例中0x90 ^ 0xAANOP 异或 key与0xC3 ^ 0xAARET 异或 key构成的密文需先用VirtualProtect把页面标记为PAGE_EXECUTE_READWRITE再逐字节异或还原。三条分析对策分别对应内存写断点抓解密时机、PIN/DynamoRIO 插桩日志记录实际执行地址、解密后 dump捕获真实代码。值得注意VirtualProtect 可写可执行页面本身就是参考文档 PE 异常检查清单中的高危特征见下文两者互为印证。面向对象编程作为混淆手段ROP as Obfuscation参考文档指出了一个反直觉的用法——ROP 链不只用于漏洞利用也用于混淆Some protectors use ROP chains not for exploitation but for obfuscation: - Replace direct CALL/JMP with a crafted stack RET - Disassembler cannot follow indirect returns easily Detection: Look for sequences of POP; RET or ADD ESP, N; RET Tools: ROPgadget, rp can enumerate; angr can follow symbolically原理把直接的CALL/JMP替换为「构造栈 RET」由于 RET 的目标是运行时从栈弹出的地址静态反汇编器很难静态跟随这类间接返回。检测手段是搜索POP; RET或ADD ESP, N; RET指令序列ROPgadget 与 rp 可以枚举 gadgetangr 则能做符号执行跟进。高级虚拟机检测技术Advanced VM Detection Techniques反逆向的另一个维度是「检测自己是否运行在虚拟化/沙箱环境中」——恶意软件据此决定是否暴露真实行为。参考文档收录了四条硬件级检测路线全部基于 x86 虚拟化架构的固有行为差异。这里的侧重点是原理与对抗逻辑与 details.md 中基于 CPUID hypervisor 位、MAC 前缀、注册表/文件痕迹的基础检测形成递进关系后者在该文档中明确引导读者「For advanced VM detection … see references/advanced-techniques.md」。RDTSC 差值校准Timing Calibration虚拟机在执行特权指令如 CPUID、IN时会触发 VM exit导致指令延迟显著高于裸机这正是计时检测的基础// Calibrate baseline on real hardware, detect anomaly in VM // VM exits on CPUID/IN instructions inflate RDTSC delta significantly static inline uint64_t rdtsc(void) { unsigned int lo, hi; __asm__ __volatile__(rdtsc : a(lo), d(hi)); return ((uint64_t)hi 32) | lo; } int detect_vm_timing(void) { uint64_t t1 rdtsc(); __asm__ __volatile__(cpuid ::: eax,ebx,ecx,edx); uint64_t t2 rdtsc(); // Bare metal: delta ~150-300 cycles; VM: delta 1000 cycles return (t2 - t1) 750; }代码要点rdtsc()内联汇编读取时间戳计数器中间插入cpuid一条必然触发 VM exit 的指令通过两次读数差值判定环境。文档给出的经验阈值是裸机约 150–300 cycles、VM 中超过 1000 cycles判定线取 750。需要强调这是经验值而非绝对事实实际受 CPU 型号、虚拟化层优化影响显著。与之呼应details.md 的 Troubleshooting 章节给出了关键工程提示RDTSC/CPUID 是 x86 专属指令在 ARM 上应改用MRS x0, PMCCNTR_EL0需内核 PMU 权限或clock_gettime(CLOCK_MONOTONIC)同时计时检测存在误报问题——Process Monitor 或杀软 hook 会拉高系统调用延迟正确做法是在启动时对受保护路径测量 3 次取mean 3*stddev作为动态阈值。这两条经验可直接套用在上面的detect_vm_timing阈值设定上。通过 IN 指令的 VMEXIT 侧信道VMware BackdoorVMware 在 I/O 端口 0x5658 提供了「后门backdoor」通信接口IN 指令到该端口的行为在裸机与 VM 中截然不同// IN instruction to port 0x5658 (VMware backdoor) causes VM exit // On bare metal: raises #GP exception; in VMware: returns data int detect_vmware_backdoor(void) { __try { __asm { push eax push ebx push ecx push edx mov eax, VMXh // VMware magic mov ecx, 10 // Get version command mov dx, 0x5658 // VMware backdoor port in eax, dx mov [is_vm], 1 pop edx pop ecx pop ebx pop eax } } __except(EXCEPTION_EXECUTE_HANDLER) { // Exception bare metal, IN caused #GP } return is_vm; }逻辑拆解eax VMXhVMware 魔数、ecx 10Get version 命令、dx 0x5658后门端口构造一次后门请求在 VMware 中in eax, dx会触发 VM exit 并被 Hypervisor 处理后返回数据is_vm置 1在裸机上该端口不存在IN 指令引发#GP 异常一般保护错误被 SEH 的__except捕获——异常发生即说明是裸机。这是非常典型的「异常路径即判定路径」反模式分析时在 x64dbg 中把EXCEPTION_ACCESS_VIOLATION/#GP类异常设为「Pass exception to program」即可观察其真实分支与 details.md 中 SEH/VEH 反调试的绕过思路一致。Hypervisor 叶子枚举CPUID Leafx86 架构为虚拟化厂商保留了 CPUID 功能号段0x40000000–0x4FFFFFFFHypervisor 通过它暴露身份// CPUID leaf 0x40000000–0x4FFFFFFF reserved for hypervisors void enumerate_hypervisor(void) { int info[4]; __cpuid(info, 0x40000000); char sig[13] {0}; memcpy(sig, info[1], 4); memcpy(sig 4, info[2], 4); memcpy(sig 8, info[3], 4); // Known signatures: // VMwareVMware → VMware // Microsoft Hv → Hyper-V // KVMKVMKVM\0\0\0 → KVM // VBoxVBoxVBox → VirtualBox // XenVMMXenVMM → Xen printf(Hypervisor: %s\n, sig); }__cpuid(info, 0x40000000)返回的 EBX/ECX/EDX 三个寄存器拼接起来就是厂商签名例如VMwareVMware、Microsoft Hv、KVMKVMKVM、VBoxVBoxVBox、XenVMMXenVMM。这一方法与 details.md 中「CPUID hypervisor 位ECX bit 31 brand string」的检测一脉相承区别是后者只回答「是否在虚拟机里」前者能进一步识别出是哪一家虚拟化产品。注意这是处理器级事实可放心作为识别依据。Guest 驱动与痕迹检测Driver/Artifact Detection最朴素的检测方式——直接查 VM 安装后必然存在的文件与注册表痕迹// Check for known VM driver files (Windows) const char *vm_drivers[] { C:\\Windows\\System32\\drivers\\vmmouse.sys, // VMware C:\\Windows\\System32\\drivers\\vmhgfs.sys, // VMware shared folders C:\\Windows\\System32\\drivers\\VBoxMouse.sys, // VirtualBox C:\\Windows\\System32\\drivers\\VBoxGuest.sys, // VirtualBox C:\\Windows\\System32\\drivers\\balloon.sys, // QEMU/KVM NULL }; int check_vm_files(void) { for (int i 0; vm_drivers[i]; i) { if (GetFileAttributesA(vm_drivers[i]) ! INVALID_FILE_ATTRIBUTES) return 1; } return 0; } // Registry artifact check const char *vm_reg_keys[] { SOFTWARE\\VMware, Inc.\\VMware Tools, SOFTWARE\\Oracle\\VirtualBox Guest Additions, HARDWARE\\ACPI\\DSDT\\VBOX__, NULL };驱动文件与注册表键均指向「安装了 Guest Tools」的虚拟机——vmmouse.sys / vmhgfs.sysVMware 鼠标与共享文件夹、VBoxMouse.sys / VBoxGuest.sysVirtualBox、balloon.sysQEMU/KVM 内存气球。参考文档中的对应绕过方案在 details.md 中有完整表述是使用裸机环境、加固 VM移除 Guest Tools、随机化 MAC、删除痕迹文件或使用加固配置的 FLARE-VM / REMnux 分析环境。加壳器/保护器检测参考Detection Reference在动手脱壳或反虚拟化之前先确认「对面是什么」永远是第一步。参考文档以 Detect-It-EasyDIE与 PE 结构特征给出了两个检测维度。DIEDetect-It-Easy签名特征- Entropy 7.0 on a section → likely packed/encrypted - Section name mismatch (e.g., .text has execwrite permissions) → self-modifying - Import table with only LoadLibrary GetProcAddress → dynamic API resolution - Single section with high entropy no readable strings → heavy packing四条启发式规则分别指向高熵7.0 说明数据被压缩/加密正常代码节熵值通常在 5.0–6.5 区间、节权限异常.text同时具备执行写入权限几乎可以断定存在自修改代码与上文VirtualProtect(PAGE_EXECUTE_READWRITE)的模式直接对应、导入表异常精简只剩LoadLibraryGetProcAddress说明所有 API 均运行时动态解析对应 details.md 中的 API 哈希与动态解析混淆、单节高熵无可读字符串重度加壳的典型形态。PE 异常检查清单Packed Binaries 版参考文档给出了一张可直接对照打勾的检查清单[ ] Section characteristics: writable executable unusual [ ] Virtual size raw size on code section unpacking stub inflates [ ] Import table almost empty (only 1-3 imports) dynamic resolution [ ] Entry point not in .text section custom stub [ ] High entropy (7.2) in any section encryption/compression [ ] Overlay data after EOF of last section appended payload [ ] TLS callbacks present early execution before main EP逐条含义节可写可执行正常 PE 中.text只读可执行RWE 权限组合强烈暗示运行时自解密/自修改Virtual size 远大于 Raw size解压 stub 在内存中膨胀导致虚拟大小远超磁盘原始大小这是压缩壳的标志性特征导入表几乎为空仅 1–3 个导入真实 API 依赖被延迟到运行时解析入口点不在.text节EP 指向壳代码所在节如UPX1说明存在自定义 stub任意节熵 7.2加密/压缩判定的更严格阈值末节 EOF 之后的 Overlay 数据附加在文件尾部的载荷如数字签名或附加 payload存在 TLS 回调TLS 回调会在主入口之前执行是恶意代码与保护器「先于 EP 运行」的常见手段。这张清单与上文「DIE 签名特征」共同构成完整的静态预检流程也是 reverse-engineer.md 中 Phase 1 Reconnaissance文件识别、元数据提取、Packer detection的具体操作化版本——在实际分析中建议先用file、Detect It Easy、dumpbin见该 Agent 的 Supporting Tools 清单完成格式与编译信息识别再套用本清单逐项核验。与技能体系协同完整调用链与合规边界本文主题文档不是孤立的技术笔记它在仓库技能体系中承担「进阶参考」角色完整调用链如下技能触发分析任务如恶意样本分析、CTF 挑战、受保护软件授权分析触发 SKILL.md其description明确覆盖「analyzing malware evasion techniques、implementing anti-debugging protections for CTF challenges、reverse engineering packed binaries、building security research tools that need to detect virtualized environments」四类场景分层取用常见模式反调试、反 VM 基础、混淆在 references/details.md进阶内容加壳内部、虚拟化保护、反反汇编、高级 VM 检测在本文档两处文档均通过相对链接互相引导形成「入门 → 详细 → 进阶」三级递进Agent 协同reverse-engineer.md二进制分析、IDA/Ghidra/x64dbg/radare2 全工具链、malware-analyst.md、firmware-analyst.md 等 Agent 会在分析受保护样本时主动引用本技能技能间亦有关联关系如 binary-analysis-patternsELF/PE/Mach-O 静态与动态分析工作流、memory-forensics进程内存采集与活体分析可与本文档的脱壳 dump、自修改代码抓取步骤配合多 harness 分发整个技能目录含references/由 tools/adapters/base.py 与各 harness 适配器如 tools/adapters/codex.py镜像到 Claude Code、Codex、Cursor、OpenCode、GitHub Copilot、Google Antigravity 等环境保证任何入口都能读到同一份进阶参考。最后重申合规前提源自 SKILL.md 的 AUTHORIZED USE ONLY 声明与 reverse-engineer.md 的 Security Ethics 章节本文所有脱壳、反虚拟化、VM 检测与绕过技术均为**双用途dual-use**安全知识只能用于已获授权的安全研究、恶意软件防御分析、CTF 竞赛、学术研究与教育目的严禁用于软件盗版、未授权访问或恶意用途。分析时应以「理解防护机制、完成合法分析任务」为唯一目标并在每个分析阶段保留授权与范围记录。总结一条可复用的进阶分析路线将本文五大部分串联起来面对任意一个受保护二进制可以按以下顺序推进分析静态预检用 Detect It Easy / Exeinfo PE 做加壳器识别对照「DIE 签名特征」与「PE 异常检查清单」确认壳类型与保护强度是否叠加虚拟化脱壳还原已知壳优先工具upx -d、UnpacMe 等修改壳按「ESP 技巧 → OEP 断点 → 内存 dump → Scylla 修 IAT」动态路线处理反反汇编对抗分析过程中对重叠指令、垃圾字节、自修改代码保持警觉必要时用内存写断点与插桩PIN/DynamoRIO获取真实执行流虚拟化攻坚若确认存在代码虚拟化按「定位 VM 入口 → trace 记录 → 建立 handler 语义表 → IR 提升VMAttack/SATURN/NoVmp/angr/Triton→ 重建 CFG」工作流推进环境判定分析恶意样本时用 RDTSC 差值校准、VMware backdoor IN、CPUID 叶子枚举、驱动/注册表痕迹确认当前环境是否被样本的 VM 检测逻辑识别必要时切换到加固的裸机分析环境。这套路线与仓库 docs/agent-skills.md 中 Reverse Engineering 技能组的定位完全吻合——先识别、再绕过、后报告始终在授权边界内完成对受保护软件的深度剖析。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考