简介这是一套面向逆向分析人员的Themida WinLicense脱壳与调试辅助工具集覆盖1.8.X至2.X版本保护程序适合具备一定Windows逆向基础、需要开展加壳识别、特征提取与脱壳流程验证的从业者。包内共292个文件约2.23MB以inc头文件、vm虚拟机皮肤、h头文件、lng多语言文件、pas与cpp源码、lib库文件及各类工程配置为主涵盖32/64位主程序、C/Delphi/Go/PureBasic等多语言开发接口、SecureEngineSDK动态库、SDK示例工程与帮助文档。资源同时提供dolphin、shark、puma、fish系列虚拟机皮肤与custom_vms自定义VM模板兼容COFF、OMF、PE等多种目标文件格式并支持定制化消息DLL与保护状态检测。目前已有86人学习下载读者可借助其完整目录结构快速定位宏定义检查、接口调用与脱壳验证所需模块减少自行搜集与拼装环境的时间成本。1. Themida/WinLicense 1.8–2.x 脱壳与调试辅助从识别版本到拿到原始 OEP手上有个老商业软件PE 头一看是 Themida/WinLicense 加壳版本落在 1.8 到 2.x 这个区间想动态调试看它到底怎么校验授权、怎么初始化核心逻辑结果 OllyDbg 一挂上去进程直接退出x64dbg 断在入口点没走几步就跳飞。这个场景在逆向老软件、做兼容性维护、分析遗留授权模块时非常常见。Themida 和 WinLicense 是 Oreans 同一套保护体系的两个产品线前者偏代码虚拟化与反调试后者在授权管理上更重1.8 到 2.x 这批版本的核心特征是虚拟机入口识别点相对固定、IAT 处理方式有规律可循但反调试手段已经相当密集。这篇笔记面向的是需要实际把壳脱掉、把原始入口点找回来、再挂调试器继续分析的一线从业者不是泛泛讲壳的原理。我会按识别版本、定位 OEP、处理 IAT、绕过反调试、验证脱壳结果这条线把每一步的命令、参数和翻车点讲清楚。2. 先判断壳版本与保护类型Themida 还是 WinLicense2.1 用区段名和入口特征区分两条产品线Themida 和 WinLicense 共用同一套加壳引擎但区段命名和入口代码模式有细微差别。常见做法是先看 PE 区段表Themida 1.8–2.x 典型区段名是.themida、.winlice或随机化的短名WinLicense 则经常出现.winlice配合一个额外的授权数据段。用dumpbin或PE-bear打开重点看三处区段数量、入口点所在区段、导入表是否被清空或指向壳内。# 用 dumpbin 看区段和入口点Windows SDK 自带 dumpbin /headers target.exe | findstr /i section entry输出里如果看到.themida或.winlice区段且 Entry point 落在该区段内基本可以确认是 Oreans 系。接着用CFF Explorer看导入表如果 Import Directory 的 RVA 指向壳区段而不是正常.idata说明 IAT 被壳接管脱壳时必须重建。参数上要注意1.8 到 2.x 之间区段名会随版本和加壳选项变化不能只靠名字。更稳的判断是看入口点前几条指令Themida 典型是pushad后跟一段call进入虚拟机WinLicense 则常在pushad前多一层授权检查跳转。我一般会同时用PEiD的 Oreans 签名和手动看入口两条路交叉验证避免误判。2.2 确认虚拟机入口与授权模块的边界Themida/WinLicense 1.8–2.x 的虚拟机入口通常是一个pushad保存现场然后call到壳的 VM 解释器。WinLicense 额外会在 VM 之前插入授权校验表现为一段独立的call返回后根据eax决定是否继续。识别这个边界很关键因为脱壳时如果只处理 VM 不处理授权跳转脱出来的程序可能直接跑飞。# 用 pefile 快速定位入口点所在区段和前后指令范围 import pefile pe pefile.PE(target.exe) ep pe.OPTIONAL_HEADER.AddressOfEntryPoint image_base pe.OPTIONAL_HEADER.ImageBase for sec in pe.sections: start sec.VirtualAddress end start sec.Misc_VirtualSize if start ep end: print(fEP RVA: {hex(ep)} in section {sec.Name.decode().strip(chr(0))}) print(fSection range: {hex(start)} - {hex(end)})这段脚本输出入口点归属区段和范围逻辑是遍历区段表比对 RVA。参数上AddressOfEntryPoint是 RVA要加上ImageBase才是 VA调试器里下断点用 VA。如果入口落在.themida且该区段 VirtualSize 远大于 RawSize说明壳在内存中展开脱壳要在内存 dump 而不是直接改文件。提示1.8 和 2.x 的 VM 入口指令长度不同2.x 常见多一层jmp跳转定位时不要死记硬编码字节用区段归属判断更可靠。3. 定位原始 OEP内存断点与栈回溯两条路3.1 用内存访问断点抓 OEP 的实操步骤找 OEP 最稳的办法是在壳解压完、跳回原始代码的那一刻下断。Themida/WinLicense 1.8–2.x 的 VM 执行完后会恢复pushad保存的寄存器然后jmp到原始入口。常见做法是在栈上找pushad保存的esp对原始代码区段下内存访问断点。# x64dbg 脚本在壳区段执行完后对代码段下内存断点 # 先运行到入口然后在命令栏执行 bpm original_code_section_start, r, 1 # 或者用硬件断点跟踪栈上的返回地址 hr esp_saved_value逻辑说明bpm是内存断点r表示读访问1是单次触发。参数original_code_section_start需要你先从 PE 区段表里找到原始代码段通常是.text的起始 VA。如果壳把原始区段也改了名就看哪个区段在解压后出现正常代码特征。触发后单步跟看到popad后跟一个远跳那个跳转目标就是 OEP。我一般会配合栈回溯在pushad处记下esp然后对[esp0x1C]这类保存的返回地址下硬件断点。1.8 版本 VM 结束后常用ret而不是jmp所以栈断点比代码断点更早命中。2.x 则更多用jmp内存断点更直接。两条路都试哪个先命中用哪个。3.2 处理 IAT 重建与区段修复OEP 找到后直接 dump 出来的文件 IAT 是坏的因为壳在运行时才填充导入表。常见做法是用Scylla或ImportREC重建 IAT。步骤是在 OEP 处暂停让 Scylla 附加到进程填 OEP 的 RVA点IAT Autosearch然后Get Imports最后Fix Dump到之前 dump 的文件上。# Scylla 命令行模式如果有或手动步骤 # 1. 在 OEP 处暂停调试器 # 2. Scylla 附加进程OEP 填 OEP RVA # 3. IAT Autosearch - Get Imports - Fix Dump参数上 OEP RVA 要填相对ImageBase的偏移不是 VA。如果 Autosearch 失败手动在 IAT 区段下内存断点运行后看哪个地址被写入函数指针那个范围就是 IAT。1.8–2.x 的 IAT 有时被壳拆成多段Scylla 的Autosearch可能只找到一部分需要手动补。修复后区段表也要修用CFF Explorer把 dump 文件的区段 RawSize 和 VirtualSize 对齐否则加载器可能拒绝加载。注意WinLicense 的授权模块可能在 IAT 重建后仍然校验自身完整性脱壳后首次运行可能触发授权失败这是正常的说明壳的校验逻辑还没处理不是脱壳步骤错了。4. 绕过反调试Themida/WinLicense 1.8–2.x 的常见检测点4.1 识别并处理调试器检测与时间差检测Themida/WinLicense 1.8–2.x 的反调试手段包括IsDebuggerPresent、CheckRemoteDebuggerPresent、NtQueryInformationProcess查ProcessDebugPort、rdtsc时间差检测、以及int 3和int 2d异常检测。常见做法是在调试器里对这些 API 下断点命中后改返回值或直接跳过。# x64dbg 命令对常见反调试 API 下断并改返回 bp IsDebuggerPresent # 命中后执行 ret 0 # 对 NtQueryInformationProcess 则要看第二个参数 bp NtQueryInformationProcess # 命中后检查 [esp8] 是否为 7 (ProcessDebugPort)是则改 [esp0xC] 指向的值为 0逻辑说明IsDebuggerPresent直接返回 0 即可。NtQueryInformationProcess的ProcessDebugPort查询会把调试端口写到输出缓冲区改成 0 就骗过。rdtsc检测比较麻烦1.8 版本常用两次rdtsc差值判断是否单步我一般会在rdtsc指令处下断手动改eax/edx让差值变小。2.x 增加了int 2d和icebp检测需要在异常处理里过滤。参数上要注意Themida 的检测不是一次性的VM 内部会反复调用所以断点要保留不能命中一次就删。WinLicense 还会检测调试器窗口标题和进程名用x64dbg时改窗口标题和进程名能减少触发。4.2 处理 VM 内部的完整性校验与代码自修改1.8–2.x 的 VM 会在执行过程中校验自身代码段是否被修改如果下了软件断点int 3校验和会变壳直接退出。血泪经验是在壳区段内不要下int 3断点用硬件断点或内存断点代替。硬件断点只有四个要省着用优先给 OEP 定位和关键跳转。# 用硬件断点代替软件断点 # x64dbg 命令栏 bph address, x, 1 # 执行断点 bph address, r, 1 # 读断点 bph address, w, 1 # 写断点逻辑说明bph是硬件断点不修改代码字节不会被完整性校验发现。参数x/r/w分别对应执行、读、写。1.8 版本对代码段校验较松2.x 会校验rdtsc前后的代码所以硬件断点也要注意时机。如果壳检测到硬件断点通过Dr0-Dr7寄存器需要手动清零调试寄存器这个在 x64dbg 里可以用脚本在异常处理时清。提示Themida 2.x 的 VM 会检测Dr寄存器如果硬件断点被识别进程会静默退出。遇到这种情况先清Dr再继续或者改用内存断点。5. 避坑与排查脱壳过程中最容易翻车的五个点5.1 现象dump 出来的文件运行直接崩溃原因通常是 IAT 没重建完整或者区段对齐没修。1.8–2.x 的 IAT 可能分散在多个区段Scylla 自动搜索只覆盖第一个。解决方法是手动在 IAT 区段下内存写断点运行后记录所有被写入的地址范围在 Scylla 里手动添加这些范围再Get Imports。另外检查 dump 文件的SizeOfImage是否和原文件一致不一致会导致加载器映射错误。5.2 现象OEP 定位后单步就跳飞原因是壳在 OEP 附近还有一段解密或重定位代码你看到的 OEP 可能是假的。1.8 版本常见手法是放多个popad和jmp第一个不是真 OEP。解决方法是跟到jmp目标后再看是否还有pushad如果有继续跟直到出现正常的函数序言push ebp; mov ebp, esp且后续代码有正常 API 调用。5.3 现象调试器附加后进程直接退出没有任何异常原因是反调试检测在附加瞬间就触发了可能是NtQueryInformationProcess或窗口标题检测。解决方法是先用x64dbg的Hide Debugger插件或手动改PEB的BeingDebugged标志再附加。WinLicense 还会检测父进程用CreateProcess启动而不是附加能减少触发。5.4 现象脱壳后程序能跑但功能异常授权校验失败原因是 WinLicense 的授权模块在脱壳后仍然校验自身代码的哈希或者依赖壳在内存中留下的某个标志。解决方法是找到授权校验的跳转在脱壳后的文件里直接nop掉或改条件跳转。1.8–2.x 的授权校验通常在 VM 之后、主逻辑之前定位方法是搜索GetVolumeInformation或注册表读取调用。5.5 现象硬件断点被检测进程静默退出原因是 Themida 2.x 会读Dr0-Dr7判断是否有硬件断点。解决方法是在 VM 执行前清空调试寄存器x64dbg 里可以用脚本在每次异常时执行dr00到dr70。或者改用内存断点内存断点不涉及Dr寄存器但会改页属性1.8 版本对页属性校验较松2.x 需要测试。6. 验证脱壳结果与进阶用原始入口点挂调试器继续分析脱壳完成后验证分三步先用PE-bear看区段和导入表是否正常再用Dependency Walker看是否有缺失导入最后直接运行看是否崩溃。如果都通过把脱壳文件用x64dbg打开断在 OEP看是否能正常单步到主逻辑。这一步能过说明脱壳基本成功。进阶用法是脱壳后不要急着分析先把原始 OEP 和关键 API 调用点记录下来用IDA加载脱壳文件做静态分析再用x64dbg动态验证。1.8–2.x 的壳脱完后主逻辑通常没有额外混淆IDA 能直接反编译出可读代码。如果还有残留的 VM 代码说明脱壳不完整需要回到 OEP 定位步骤重新跟。我自己的习惯是每次脱壳前先备份原始文件和内存 dump脱壳过程中每改一个参数就记一笔因为 Themida 的版本差异很大同一个步骤在 1.8 能过在 2.x 可能就翻车。后悔药就是备份没有备份的脱壳都是赌博。另外脱壳只是手段最终目的是分析逻辑或做兼容不要为了脱壳而脱壳能动态调试解决的就不要硬脱。希望帮到你。本文还有配套的精品资源点击获取