UPX手动脱壳实战：从定位OEP到IAT修复的完整指南

最近在分析一个加壳样本的时候，upx -d 直接罢工——不是版本不匹配，就是有人改过 UPX 的壳入口，自动解压逻辑完全跑不起来。折腾了半小时之后我意识到，与其在那儿和自动脱壳工具死磕，不如老老实实用调试器手动走一遍。手动脱壳听起来很“上古”，但它恰恰是理解 PE 结构、导入表、内存映像和程序入口关系最快的一条路。这篇文章就完整记录一次 UPX 手动脱壳的实战过程，包括工具选择、定位原始入口点（OEP）、内存转储、IAT 修复以及中间踩过的几个典型坑。无论你是刚接触逆向的小白，还是被各种魔改壳折磨过的老手，这套思路都能直接派上用场。

我先说明一下定位：UPX 是一个开源的可执行文件压缩工具，它本身是合法且广泛使用的。这篇文章讲的手动脱壳，是面向安全分析、CTF 解题、自己写的程序调试、或者分析已获授权的样本这些正向场景。别拿它去对付别人的商业软件，那是给自己找麻烦。

1. 为什么 UPX 是学习手动脱壳的最佳入门样例

1.1 UPX 加壳文件的特征与识别

UPX 加过壳的程序，在文件层面有几个非常明显的特征。首先是区段（Section）命名。PE 文件打开后，通常能看到 UPX0、UPX1、UPX2 这种名字：

• UPX0：壳解压后代码段的映射区，一般情况下文件里的 Raw Size 为 0，运行时才在内存中占用空间。
• UPX1：存放压缩后的数据，包括原程序的代码和导入表信息，是文件里真正占体积的部分。
• UPX2：某些版本的 UPX 会额外使用一个只读数据段，承载解压所需的部分常量。

第二个特征是入口点（AddressOfEntryPoint）指向的位置不在正常的代码段内，而在最后一个节区附近，这种“入口异常”往往是杀软或者分析工具判定它被加壳的第一信号。第三个特征是区段属性：UPX0、UPX1 的内存权限通常被设置为可读可写可执行（0xE0000020），因为运行时要在这个段内动态解压并执行代码。

提示：UPX 加壳后的文件并不是把压缩数据“藏”起来了，它只是改变了 PE 的加载方式。文件加载进内存后，壳代码先行执行，在内存里把原始指令解压回 UPX0 段，再跳转到原始入口点。手动脱壳的核心，就是找到这个“跳转之后的位置”，把内存里的完整程序镜像“捞”出来。

1.2 手动脱壳的本质：壳与 PE 加载过程的关系

我见过不少初学者把脱壳理解成“把文件解开，得到一个和新的一样能跑的程序”。这个说法方向没错，但容易忽略一个关键点：壳的本质不是一个加密文件容器，而是一段“先行加载代码”。

PE 文件被 Windows 加载器读入内存后，控制权先交给壳的入口代码。壳代码完成三件事：

1. 按区段解压原始指令到对应的内存地址；
2. 重建原始程序运行所需的导入表（IAT）、重定位表等数据结构；
3. 跳到原始入口点（OEP），让原程序的主逻辑接管控制流。

所以手动脱壳的完整流程对应着这三件事：让壳代码执行完毕，停在 OEP；把当前进程的内存镜像转储成文件；修复转储文件的导入表，保证它脱离壳代码后依然能正常加载。任何一个环节没做对，转出来的文件要么起不来，要么一运行就崩。

这也就是为什么我强调“手动脱壳是理解 PE 的最佳实践课”。你给一个 PE 文件做脱壳，相当于把操作系统加载 PE 的流程亲手走了一遍：区段映射、内存与文件偏移的换算、IAT 在哪里、重定位表怎么处理。这些知识在正常写代码的时候根本不会碰到，但一旦碰上“这程序为什么加载不了”“为什么启动就崩溃”这种问题，它们就是救命的东西。

1.3 为什么 UPX 是“最温柔”的壳

UPX 之所以适合入门手动脱壳，是因为它的解压逻辑非常规整。它不像一些商业壳那样有大量的反调试器检测、虚拟机保护、代码混淆，也没有把程序逻辑加密到失去明文特征的程度。它就是一个老实本分的压缩器，壳代码的执行流程几乎是线性的：

保存现场（x86 下是 pushad 之类的指令）→ 逐段解压 → 恢复现场（popad）→ 跳转 OEP。

这样一个流程给了调试器很大的操作空间，不管是“ESP 定律”“内存断点法”还是“单步跟踪法”，都能比较稳定地定位到 OEP。学会在 UPX 上把这些方法跑通了，再面对稍微复杂一点的压缩壳或者指令壳，你的手感就完全不一样了。

2. 环境准备与工具清单：先搭一个安全的调试环境

2.1 工具选型：不是越多越好，关键是顺手

手动脱壳要看的东西很多：PE 结构、内存布局、导入表、断点状态。一套顺手的工具能节省大量时间。我个人常用的组合如下：

注意：环境一定要干净。做脱壳调试时，尽量在隔离的虚拟机里进行。加壳程序，尤其是来源不明的样本，可能捆绑了恶意行为；即便你认为它只是 UPX 加壳，也不能排除程序本身有问题。虚拟机快照可以快速回滚，这是安全底线。

2.2 样本准备与合法使用边界

准备练习样本时，请遵循正规渠道：

• 自己写一个简单的 C/C++ 程序，编译后用 upx 命令压缩。这是最可控的练习方式。
• 从官方 UPX 项目仓库拿测试样本。
• 参加 CTF 比赛，赛题里通常会有若干 UPX 加壳的逆向题。
• 分析已获得授权的、用于安全研究的恶意软件样本。

在 Windows 上编译一个带窗口或控制台输出的简单程序，然后执行：

bash复制upx -o packed.exe original.exe

动手之前可以用 upx -l packed.exe 查看压缩格式信息，确认是不是标准 UPX 壳，这样后续得到的任何异常结果都能判断是操作问题，而不是样本本身就特殊。

2.3 调试器环境的基本配置

x64dbg 打开后，有几个设置我建议先调好：

1. 忽略所有断点异常：在“选项 → 首选项 → 异常”里，把异常全部勾选为“忽略”。壳代码经常通过触发异常来对抗调试器，UPX 虽然不常这么做，但你也不希望调试器在 Access Violation 上反复停住。
2. 开启动态基址随机化（ASLR）识别：如果目标程序开启了 ASLR，每次加载的基址都会变。为了调试稳定，可以在“选项 → 首选项 → 调试事件”里设置“在系统断点处暂停”，然后手动关闭程序的 ASLR。更省事的方法是用 PE-bear 直接修改 PE 头里 DllCharacteristics 字段，去掉 0x0040（IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE）标志。对于练习样本，直接把 ASLR 关掉能省很多麻烦。
3. 显示相对地址：x64dbg 默认显示绝对虚拟地址（VA）。脱壳过程中我更喜欢用模块基址加偏移的显示方式（模块名+偏移），这样在比对内存转储和文件偏移时不容易混乱。

准备完环境，下一步就可以上真东西了。

3. 实战演练：完整手动脱壳一个 UPX 加壳的 32 位程序

我以 32 位程序为例，因为 UPX 在 x86 下的壳入口逻辑非常经典，包含完整的 pushad/popad 过程，演示起来最直观。64 位的 UPX 壳逻辑有所不同，但思路一致，我会在文后单独说明差异。

3.1 定位 OEP：从“ESP 定律”开始

假设我编译了一个 hello.exe，然后 UPX 压缩成 hello_packed.exe。用 x32dbg 打开，程序会停在系统断点（EntryBreakpoint 或 ntdll 的断点）。按 F9 运行到用户入口，也就是壳的入口点。

这一步你会看到类似这样的反汇编：

code复制0040D000 >  60               pushad
0040D001   BE 00 A0 40 00    mov esi, 0040A000
0040D006   8BBE 00000000     mov edi, dword ptr ds:[esi]
...

第一行 pushad 就是壳代码保存现场的标志，它将 8 个通用寄存器的值全部压入栈中。pushad 执行之后，栈顶位置存放的是 EAX 的原始值。ESP 定律的核心逻辑就是围绕这个栈顶展开的：

1. 在 pushad 之后，记下当前 ESP 的值。
2. 对这个 ESP 地址下一个硬件断点，断点访问类型选“Dword”，访问权限选择“写入”或“访问”。
3. 继续运行程序。壳代码在函数执行结束前一定会执行 popad，而 popad 会从栈顶恢复到 pushad 保存的寄存器值，也就是读取 ESP 指向的内存。
4. 一旦读取了 ESP 地址，硬件断点立刻触发，此时壳代码已经执行完解压逻辑，正在恢复现场。
5. 取消这个硬件断点，单步几条指令，大概率就会看到类似 jmp 00401000 或 push 00401000; retn 的结构。这个跳转目标，就是 OEP。

我实际操作时，通常会在硬件断点触发后再 F8 单步一次，观察是否落在 popad 上。若落在 popad 之后的 ret 或 jmp 上，就说明离 OEP 只差一步。如果断点触发后看到的不是 popad，则可能遇到修改过的 UPX 变体，需要退回到 pushad 的位置重新分析。

3.2 到达 OEP：单步跟踪与断点策略

ESP 定律定位到跳转指令后，下一步就是确认 OEP 地址。假设调试器显示：

code复制0040D020    8D4424 80       lea eax, dword ptr ss:[esp-0x80]
0040D024    6A 00           push 0
0040D026    39C4            cmp esp, eax
0040D028  ^ 75 FA           jnz short 0040D024
0040D02A    83C4 80         add esp, -0x80
0040D02D    85ED            test ebp, ebp
0040D02F  ^ 74 0B           je short 0040D03C
0040D031    8B06            mov eax, dword ptr ds:[esi]
0040D033    894424 04       mov dword ptr ss:[esp+0x4], eax
...
0040D0E0    61              popad
0040D0E1    75 08           jnz short 0040D0EB
0040D0E3    B8 00000000     mov eax, 0
0040D0E8    6A 00           push 0
0040D0EA    68 00104000     push hello_pa.00401000   ; OEP 候选
0040D0EF    C3              retn

看到 push 00401000; retn 这种结构时，OEP 就是 0x00401000。在这个位置设置一个普通断点，运行过去，验证一下：

• 程序是否停在了 0x00401000。
• 该地址附近是否是常见的编译器入口代码，比如 VC++ 程序的入口通常会调用 GetCommandLineA，再调用 mainCRTStartup。

如果你看到的是 push ebp; mov ebp, esp; sub esp, 0x40 这种典型的函数序言，那基本可以确定 OEP 找对了。

提示：现代编译器生成的入口代码不全是 push ebp 开头，也可能是 xor ebp, ebp; push ebp; mov ebp, esp，甚至直接是 mov edi, edi 的 stub。关键不在于第一条指令长什么样，而在于它的上下文是否连续、是否引用了正常的 API 调用。

3.3 内存转储：把进程镜像“倒”出来

OEP 确定之后，程序此刻还运行在壳的“毛坯房”里——内存中的原始代码已经被解压完毕，但文件里仍然是壳数据。现在需要把内存映像保存下来。

x64dbg 的 File → Dump memory to file 或 Scylla 插件的 Dump 功能都能完成这件事。不过我建议直接用 Scylla，因为它能把转储和 IAT 修复无缝衔接。

在 OEP 处断下后，打开 Scylla（x64dbg 中通过插件菜单打开），操作步骤如下：

1. 选择进程：Scylla 会自动关联当前调试的进程。
2. 填写 OEP：把刚才确认的 0x00401000 填进“OEP”输入框。
3. 选择转储范围：默认会转储整个加载镜像，但我会手动检查区段信息。PE-bear 里显示的区段 Virtual Address 和 Virtual Size 是转储时的参考依据。
4. 点击 Dump：Scylla 会生成一个 dump.exe 文件。

此时生成的 dump.exe 其实还“跑不起来”，因为它用的是壳原来的 PE 头，区段映射和导入表都指向壳的旧数据结构。如果把整个镜像按内存布局转储，新文件的区段 Raw 尺寸可能不对，导入表也完全缺失。所以转储只完成了一半工作，下一步才是重头戏。

3.4 修复导入表：没有有效 IAT 的转储文件是残缺的

为什么转储之后必须修 IAT？因为加壳程序在运行时，导入表是由壳代码动态重建的。原始 PE 文件里的导入表可以指向文件某个固定偏移，也可以指向内存中某个运行时地址；壳会把原始 IAT 数据压缩保存，并在解压后重新构建 IAT。等你用调试器把内存转储成文件时，转储文件里的 IAT 数据是“内存态”的，脱离了正在运行的进程，Windows 加载器无法识别它。

Scylla 修复 IAT 的步骤：

1. 在 Scylla 窗口中，点击 IAT Autosearch，它会扫描当前进程内存，尝试定位导入表。
2. 扫描结果会显示一个地址范围和大小，通常是 0x00401000 附近或 0x0040A000 附近。
3. 点击 Get Imports，Scylla 会解析出导入的 DLL 和函数列表。检查列表里是否有“无效”条目（通常是地址为 0 或指向无效内存的条目）。
4. 如果列表正常，点击 Fix Dump，选择刚才生成的 dump.exe。

Fix Dump 会创建一个 dump_SCY.exe（实际上是修复后的文件），此时这个文件才真正具备“可运行”的基本条件。

提示：Scylla 的“Autosearch”偶尔会识别错范围，特别是当程序有动态加载的 API 或者反调试逻辑时。如果识别出的 IAT 范围明显不对，可以手动在内存窗口中跳转到 push OEP 附近的引用地址，往上追几个 jmp [addr] 结构，找到导入函数的跳转表，把地址和大小填进去。这个手动定位 IAT 的过程比较考验经验，但第一次做成功之后会对 PE 导入表有更深的理解。

3.5 验证修复结果：能不能跑不是唯一标准

修复后的文件能运行只是第一步。我会再用 PE-bear 打开 dump_SCY.exe，检查三件事：

1. 区段名和 Raw Size：如果 PE-bear 显示某个区段的 Raw Size 仍然是 0，但 Virtual Size 很大，说明这个区段在文件里没有数据，运行时就会变成空洞，程序加载后可能崩溃。
2. 入口点是否等于 OEP：PE 头里 AddressOfEntryPoint 应该指向 0x1000 等实际代码偏移，而不是壳的偏移。
3. 导入表是否完整：切换到导入表视图，确认 kernel32.dll、user32.dll 等关键 DLL 的函数都有名称，而不是一堆可疑的地址。

如果检查发现异常，直接双击运行修复后的文件，通常会在启动的一瞬间因为缺少依赖或导入表损坏而崩溃。这时候回到第 4 节的排查流程，逐项核对。

4. 修复过程中最容易踩的坑

4.1 转储时机不对导致 OEP 位置错误

最常见的失败原因就是转储时机不对。很多新手在 ESP 硬件断点触发后，看到 push 00401000 就急着转储，但这个 00401000 地址上的代码可能还没被完全解压完。UPX 的解压是分段的，不是一次全部解压完成。ESP 断点触发只能说明寄存器保存的现场准备恢复了，不代表所有区段都已经填充完毕。

正确做法是：在可疑 OEP 处设置断点，运行过去之后，再确认这个地址附近的指令是有效的可执行代码。如果看到一堆 00 或 CC，说明解压还没完成，需要重新回到壳入口，分析壳代码的分段解压逻辑。

另一种情况是 OEP 找错了。如果你断下的位置是一个 jmp 到壳自身的跳转，而不是原始入口，那么转储出来运行时会一进入 OEP 就执行壳代码，结果要么死循环，要么崩溃。验证 OEP 最稳妥的办法是看这个地址是否落在某个区段（通常是最开始映射的代码段）的 Virtual Address 范围内，以及该区段是否带有“包含代码”的属性。

4.2 区段映射与 Raw Size 不一致

这是一个非常隐蔽的坑。PE 加载器在映射文件到内存时，按区段头里的 VirtualSize 和 RawSize 分配内存并拷贝数据。UPX 加壳时，UPX0 段的 Raw Size 是 0，但 Virtual Size 非常大。手动转储时，Scylla 默认把整个内存镜像写进文件，如果没有同步修正每个区段的 PointerToRawData 和 SizeOfRawData，生成的 dump 文件里，区段的数据偏移会全部错位。

症状：修复后文件一运行就报“不是有效的 Win32 应用程序”，或者加载后函数指针全是错的。

解决办法：用 PE-bear 或 CFF Explorer 打开 dump 文件，逐个区段调整：

• Virtual Address 保持不变；
• Virtual Size 可以保持内存中的尺寸；
• PointerToRawData 要设成该区段在文件中的实际偏移；
• SizeOfRawData 要覆盖该区段实际写入文件的数据量，通常不小于 Virtual Size，但也不能大到超出文件末尾。

一个快速经验做法是：转储后直接看文件大小，然后按区段顺序把 PointerToRawData 设置成“上一区段文件偏移加上一区段文件大小”，把 SizeOfRawData 设置成“本区段 VirtualSize 与文件剩余空间的最小值”。这样做虽然不算优雅，但能快速让文件可以被加载器识别。

4.3 IAT 识别错误导致函数地址全部错乱

Scylla 的自动识别大部分情况下是准的，但遇到 UPX 压缩过的程序时，IAT 可能被壳代码分解成多个数据块，或者一部分导入函数被延迟绑定。Scylla 在 Get Imports 后如果看到大量红色条目（函数地址为 0），先别急着点 Fix Dump。

红色条目通常意味着三种情况：

1. 壳代码还没有把该函数地址填回 IAT，也就是程序还没真正调用到那个 API。
2. 导入表被拆分到了多个地址范围，Autosearch 只找到了一部分。
3. 这个函数是通过 GetProcAddress 动态获取的，根本不在静态导入表里。

第一种情况，解决方案很简单：把断点设置在 OEP 处时，程序已经执行完壳代码，正常情况所有静态导入都应该被填充。如果仍然有 0，检查是不是 OEP 找错了。第三种情况比较麻烦，需要手动分析壳代码里的 GetProcAddress 调用逻辑，把动态解析的 API 手工填充进去。

4.4 附加数据与资源没有保存

UPX 除了压缩代码段，也会压缩资源段（.rsrc）。如果原程序里包含图标、对话框、字符串表等资源，UPX 解压后它们会出现在内存中。Scylla 转储时虽然会把资源段一起 dump 下来，但资源段的 Raw Size 可能和 Virtual Size 不一致，导致资源查看器打开时报错。

另一个容易忽略的问题是 Overlay 数据。很多程序在 PE 文件末尾附加了签名、证书、配置等数据。UPX 默认会保留这些 Overlay 数据，但手动转储时这些数据不会自动出现在 dump 文件里。修复后文件可能能运行，但数字签名会失效，配置文件读取会失败。

检查方法：用 PE-bear 打开原始加壳文件和 dump 文件，对比文件大小和区段表末尾的偏移。如果原始文件末尾有多余的附加数据，需要手动把它追加到 dump 文件的末尾，并修正 PE 头的 SizeOfImage 和区段表，确保加载器能映射到附加数据所在的位置。

提示：某些程序会在 startup 时校验自身签名，如果 Overlay 数据对不上，程序即便能启动，后面也会出现诡异的崩溃或者功能缺失。遇到这种现象，先检查 Overlay，别一上来就怀疑脱壳没脱干净。

4.5 32 位与 64 位 UPX 壳的差异

x64 下的 UPX 壳入口不会用 pushad，因为 x64 指令集没有 pushad。实际看到的是多条 push 指令保存寄存器，或者直接用 mov 将寄存器值保存到栈上。ESP 定律对应的方法在 x64 依然有效，但需要找到“保存现场”和“恢复现场”的对应关系。

我在 x64 下调试 UPX 时，更常用的方法是内存断点法：在数据窗口里跳到 UPX0 段（代码段）的起始位置，对该地址下内存访问断点。当壳代码解压完成并首次跳转到原始入口时，内存访问断点会命中。如果没有命中，说明壳代码没有直接跳过来，而是先做了别的处理（比如修复重定位表），这时再结合单步跟踪补齐。

64 位 UPX 的 OEP 通常是 0x140001000 这种高地址，转储和 IAT 修复的流程与 32 位完全一致。Scylla 在 x64dbg 中同样工作正常。

5. 手动脱壳与自动脱壳的取舍

5.1 什么时候直接用 upx -d 就够了

标准 UPX 壳、原版未修改的情况下，upx -d 就是最快的方案。它不仅能还原原始 PE 结构，还会把区段名、入口点、导入表全部恢复成加壳前的样子，比手动脱壳的结果更干净。

当你的目标只是“让程序跑起来”或者“快速看下字符串”，直接 upx -d 没问题。甚至很多杀软在静态扫描时也会先尝试 UPX 解压，然后再做特征匹配。日常分析流程里，我习惯先用 upx -d 试试，失败了再上调试器。

5.2 什么情况必须手动处理

以下情况，自动脱壳会失效或产生错误结果：

• UPX 版本不一致：高版本 UPX 加了新的解压逻辑，老版本工具识别不了。
• UPX 被修改过：有人改了 UPX 的壳入口、区段名，或者混合了其他混淆手段，UPX 拿到文件后无法识别它自己的格式。
• 需要分析壳代码本身：有些恶意软件会在壳的解压过程中加入反调试、反虚拟机、解密字符串等操作，这时候自动脱壳会错过大量关键行为。
• 需要精确的内存态样本：某些样本运行时动态生成的数据不在文件里，只有通过内存转储才能拿到完整镜像。

5.3 手动脱壳带来的额外收益

手动脱壳这件事，表面上看是在“解压缩”，实际上每一次单步跟踪都在强迫你回答一个问题：为什么壳要在这个位置做这件事？

走到 popad 时你会理解，壳在保存原程序运行时状态，以便最后跳转时“假装什么都没发生过”；走到 ret 跳转时你会理解，壳为什么不用一个简单的 jmp 而是用栈操作的技巧，因为这样做可以迷惑静态扫描的代码特征；修复 IAT 时你会理解，PE 加载器的导入解析机制到底是怎么工作的，为什么一个 DLL 导出函数地址可以同时被标记为“跳转”和“调用”。

这些理解，是任何自动脱壳工具都无法带给你的。对我个人来说，手动脱完第一个 UPX 壳之后，回头再看正常的 PE 文件导入表，脑海里会自动浮现出内存中那一片跳转表的布局，分析其他壳时下手快了很多。

提示：如果你准备长期做逆向分析，建议手动脱壳之后，再尝试用 dumpbin 或 objdump 对比修复前后文件的导入表差异，你会看到更直观的数据变化。

5.4 一个快速排查清单

脱壳修复后如果程序仍然异常，按照以下顺序排查：

1. 入口点是否为 OEP：dumpbin /headers dump_SCY.exe | findstr "entry" 或者在 PE-bear 中查看。
2. 区段的 Raw Size 是否覆盖了完整数据：查看每个区段的 PointerToRawData + SizeOfRawData 是否超出文件末尾。
3. IAT 的导入函数是否都是有效地址。
4. 是否有 Overlay 数据没补齐。
5. 是否因为 ASLR 导致重定位表异常，可在 PE-bear 中临时关闭 ASLR 再试。

这个清单能解决 80% 以上的“脱壳后跑不起来”问题。剩下 20% 是样本本身存在动态解密、自校验等特殊逻辑，需要结合动态调试逐条定位。

6. 从手动脱壳延伸到其他壳：思路比工具更重要

掌握 UPX 的手动脱壳后，你会发现自己面对其他壳时不再那么慌了。壳的本质都是“提前执行一段逻辑，然后跳回原程序”，不同的是这段逻辑有多复杂、有多少反调试手段、用什么样的方式保存和恢复现场。

比如面对 ASPack、FSG 这类小体积压缩壳，ESP 定律依然适用，因为它们同样要保存现场、解压、恢复现场、跳转。面对 MEW、Petite 这类稍微有点混淆的壳，可以先用内存断点法确定 OEP 的大致范围，再单步微调。面对加上了反调试的壳，就需要结合 IsDebuggerPresent、NtQueryInformationProcess 等 API 的反反调试技巧了，但那时你的调试基本功已经不会成为瓶颈。

工具会更新换代，但“找到 OEP → 转储 → 修复 IAT → 修正区段”这个流程框架，在 Windows PE 体系下面几十年都不会变。UPX 是练习这个框架最合适的工具——它简单、稳定、开源，所有细节都能查。练好了它，你也就练好了逆向入门的第一层地基。

我在实际分析中最大的体会是：手动脱壳没有“标准答案”，只有“当前情况下最合理的路径”。同一个样本，你可以在 ESP 断点触发后直接转储，也可以慢慢单步走到真正的 OEP 再转储，两种方法结果不同，但都能用。关键是你要清楚地知道每一步操作正在改什么、为什么改，而不是机械地照着教程点按钮。有了这个底子，以后再遇到各种奇奇怪怪的壳，至少不会被一个 upx -d 失败就卡住整个分析流程了。