executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
re-packer-id壳与混淆器识别:签名/节名/EP/熵。触发词:查壳、加壳识别、packer、壳名、UPX
Independent GitHub snapshot · Automated classification · Original documentation governs
静态识别可免沙箱([[re-analyze/platform-tips]] 最高原则:静态分析可免沙箱);工具先验证再使用。
Horsicq/Detect-It-Easy 下载 die_lin64_portable_<ver>.tar.gz 解压即用(CLI diec / GUI die);Debian/Ubuntu 也可 apt install die(仓库版较旧,签名库不全时用官方版)brew install --cask detect-it-easydie_win64_portable_<ver>.zip 解压,GUI die.exe / CLI diec.exediec --versionPEiD 0.96/0.97 签名库更新包;DIE 识别不出时用它交叉验证apt install file binutils / dnf install file binutils / pacman -S file binutilsxcode-select --install)file --version、strings --versionapt install python3 / 多数系统自带;验证 python3 --versionapt install ent / brew install ent;验证 ent(无参打印 usage)binwalk -E sample.exe | headpip install pefilepython3 -c "import pefile"按顺序执行,每步记录结果(证据路径 + sha256,见 [[re-triage]])。识别结论(壳名 / 未知壳 / 无壳 + OEP 线索)是脱壳路径的输入。
初步特征收集(file/strings):
file sample.exe
sha256sum sample.exe
strings -n 6 sample.exe | head -30
加壳样本通常:可读字符串极少、EP 附近有壳签名(UPX 头有 UPX! 魔数、ASPack 等节名特征);干净样本字符串丰富。
签名库扫描(DIE/PEiD):
diec sample.exe # CLI 扫描;GUI 用 die
PEiD(Windows): 拖入样本,看壳名 / Entrypoint / Section / Overlay 四栏签名。结果三档:明确壳名(UPX 0.89~3.xx / ASPack / FSG / VMProtect…)、可疑特征(仅入口点或节名命中)、未识别。未识别不代表干净(见坑 1)。
节名异常检查:
objdump -h sample.exe | head -30
特征:UPX0/UPX1、.aspack、.adata、.petite、全大写自定义节名、节表数量或排列异常。节名可被伪装成 .text/.data(见坑 2),节名正常仍需结合步骤 4-6。
入口点指向检查(EP 是否非首节):
objdump -f sample.exe # 看 start address
python3 - <<'EOF'
import pefile
pe = pefile.PE('sample.exe')
ep = pe.OPTIONAL_HEADER.AddressOfEntryPoint
for s in pe.sections:
va, vs = s.VirtualAddress, s.Misc_VirtualSize
if va <= ep < va + vs:
print("EP 位于节:", s.Name.rstrip(b'\x00').decode(), hex(va))
EOF
正常 PE 的 EP 指向首节 .text;EP 指向非首节 / 可写节 → 强壳特征。
熵 > 7 判断:
ent sample.exe # 整文件熵(可选)
binwalk -E sample.exe | head -20 # 熵分布图,高熵段 = 压缩/加密
python3 - <<'EOF'
import math, collections
d = open('sample.exe','rb').read()
c = collections.Counter(d); n = len(d)
h = -sum((v/n) * math.log2(v/n) for v in c.values())
print(f"entropy = {h:.3f} bits/byte")
EOF
熵 > 7.0 bits/byte → 可疑加壳/加密;逐节熵更有意义(壳节高熵、代码节低熵的混合分布也是壳特征)。
导入表极小特征:
objdump -p sample.exe | grep -A6 'DLL Name' | head -20
正常 PE 导入成百上千 API;加壳 PE 常只导入 kernel32.dll 的 LoadLibraryA/GetProcAddress 等少量 API(其余运行时动态解析)。导入表极小 + 熵高 → 几乎可断定加壳。
先记 OEP 线索(识别阶段就做,别等脱壳时):
objdump -d sample.exe | sed -n '1,20p' # EP 附近指令
简单压缩壳入口常以 pushad/pusha 开头(ESP 定律前提);强壳入口常是 push imm32; mov reg, imm; jmp vm_handler 形态。记录入口指令序列与入口地址,脱壳时直接用作断点与 OEP 判断依据。
.text/.data 看不出异常,但熵高、EP 指向第二节;原因——壳故意改名节表;对策——节名只作线索不作依据,交叉验证 EP 位置 + 熵 + 导入表upx -d 解包后 file 仍报壳特征;原因——多层加壳(UPX 里包 Themida 等);对策——脱一层重识别一层,逐层循环复查四要素:PE header(新 EP 位置 / 节表结构 / 头字段)、节名(是否出现新壳节特征)、熵分布(是否有新高熵节)、导入表(是否仍极小 / 只剩 GetProcAddress 动态调用)——四要素全部正常才算脱净,任何一项异常就回到本技能重跑.vmp0/.vmp1/.themida 节是否存在、入口是 VM 分发型还是普通 stub、位数),交由 [[re-anti-analysis]] 决定走 [[re-unpack-simple]] 还是 [[re-unpack-advanced]] 流程