re-packer-id

パッカーと難読化ツールの識別

使用する場合／使用しない場合

• 使用する：未知のサンプルを入手したら、まずパックされているかを確認し、パッカー名を特定してアンパックの手順を選択します。静的な初期調査で、エントロピーが高い／セクション名が異常／インポートテーブルが極端に小さい（[[re-triage]] の出力を参照）ことが判明し、さらに確認が必要な場合
• 使用する：動的解析の前に「観察された挙動がパッカーによるものか、プログラムによるものか」を判断します
• 使用しない：対象がすでにクリーンなサンプルで、すぐにロジックを確認する場合（[[re-binary-core]] に移動）
• 使用しない：パッカー名が正確に判明していて、アンパック作業だけが必要な場合（そのまま [[re-unpack-simple]] / [[re-unpack-advanced]] に進み、識別手順は省略できます）
• 注意：識別できないこと ≠ パックされていないこと（シグネチャデータベースが不完全／マイナーなパッカーの可能性があります）。特徴を組み合わせて判断し、必要に応じて未知のパッカーとして手動の手順を実施してください

ツールの準備

静的識別ではサンドボックスは不要です（[[re-analyze/platform-tips]] の最優先原則：静的解析ではサンドボックスを使用しなくてもかまいません）。ツールは使用前に動作確認してください。

Detect It Easy（DIE、クロスプラットフォームの主力）

• Linux：公式 GitHub release Horsicq/Detect-It-Easy から die_lin64_portable_<ver>.tar.gz をダウンロードして展開すれば使用できます（CLI diec / GUI die）。Debian/Ubuntu では apt install die でもインストールできます（リポジトリ版は古い場合があるため、シグネチャデータベースが不完全な場合は公式版を使用してください）
• macOS：brew install --cask detect-it-easy
• Windows：公式 release の die_win64_portable_<ver>.zip を展開します。GUI は die.exe / CLI は diec.exe です
• 確認：diec --version

PEiD（Windows の老舗ツール、DIE を補完）

• Windows 専用（Wine でも実行できます）：PEiD 0.95（GitHub ミラー）をダウンロードします。PEiD 0.96/0.97 のシグネチャデータベース更新パッケージとの併用を推奨します。DIE で識別できない場合は、クロスチェックに使用してください
• 確認：PEiD を開いてサンプルを読み込み、パッカー名／エントリーポイントの特徴が表示されることを確認します

file / strings（初期の特徴確認）

• Linux：apt install file binutils / dnf install file binutils / pacman -S file binutils
• macOS：Xcode Command Line Tools に付属します（xcode-select --install）
• Windows/WSL：WSL 内で Linux パッケージを使用します
• 確認：file --version、strings --version

エントロピーの計算（主に python3、ent/binwalk は任意）

• python3：apt install python3／多くのシステムに標準で付属します。確認：python3 --version
• ent（任意）：apt install ent / brew install ent。確認：ent（引数なしで usage が表示されます）
• binwalk（任意、エントロピーグラフ）：インストール方法は [[re-fw-extract]] を参照してください。確認：binwalk -E sample.exe | head

pefile（任意、PE のセクション／EP／インポートテーブル用スクリプト）

• 全プラットフォーム：pip install pefile
• 確認：python3 -c "import pefile"

操作手順

順番に実施し、各手順の結果を記録してください（証拠のパス + sha256。[[re-triage]] を参照）。識別結果（パッカー名／未知のパッカー／パッカーなし + OEP の手がかり）は、アンパック手順を選ぶ際の入力になります。

1. 初期特徴の収集（file/strings）：

   file sample.exe
   sha256sum sample.exe
   strings -n 6 sample.exe | head -30
   

   パックされたサンプルでは通常、読み取り可能な文字列が非常に少なく、EP 付近にパッカーのシグネチャがあります（UPX ヘッダーには UPX! マジックナンバーがあり、ASPack などはセクション名に特徴があります）。クリーンなサンプルでは文字列が豊富です。

2. シグネチャデータベースのスキャン（DIE/PEiD）：

   diec sample.exe          # CLI 扫描；GUI 用 die
   

   PEiD（Windows）：サンプルをドラッグして読み込み、パッカー名／Entrypoint／Section／Overlay の 4 項目のシグネチャを確認します。結果は 3 段階です：パッカー名が明確（UPX 0.89~3.xx / ASPack / FSG / VMProtect…）、疑わしい特徴（エントリーポイントまたはセクション名のみ一致）、未識別。未識別でもクリーンとは限りません（落とし穴 1 を参照）。

3. 異常なセクション名の確認：

   objdump -h sample.exe | head -30
   

   特徴：UPX0/UPX1、.aspack、.adata、.petite、すべて大文字のカスタムセクション名、セクションテーブルの数や並び順の異常などです。セクション名は .text/.data に偽装されている場合があります（落とし穴 2 を参照）。セクション名が正常でも、手順 4～6 と組み合わせて確認してください。

4. エントリーポイントの指し先を確認（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 が先頭以外のセクション／書き込み可能なセクションを指している場合は、パッカーの強い特徴です。

5. エントロピーが 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 を超える場合は、パックまたは暗号化されている疑いがあります。セクションごとのエントロピーのほうが有用です（パッカーのセクションが高エントロピーで、コードのセクションが低エントロピーという混在した分布も、パッカーの特徴です）。

6. インポートテーブルが極端に小さいか確認：

   objdump -p sample.exe | grep -A6 'DLL Name' | head -20
   

   通常の PE は数百から数千の API をインポートします。パックされた PE では、kernel32.dll の LoadLibraryA/GetProcAddress など、少数の API しかインポートしない場合があります（残りは実行時に動的に解決されます）。インポートテーブルが極端に小さく、エントロピーが高い場合は、ほぼ確実にパックされています。

7. OEP の手がかりを先に記録（識別段階で実施し、アンパック時まで待たない）：

   objdump -d sample.exe | sed -n '1,20p'    # EP 附近指令
   

   単純な圧縮パッカーのエントリーポイントは pushad/pusha で始まることがよくあります（ESP 定理が前提）。強力なパッカーのエントリーポイントは、push imm32; mov reg, imm; jmp vm_handler の形式であることがよくあります。エントリーの命令列とアドレスを記録してください。アンパック時にブレークポイントの設定と OEP の判断にそのまま使えます。

分野横断の連携

• [[re-anti-analysis]]：ワークフローの第 1 ステップ（パッカーの識別）で本スキルを必ず呼び出します。識別結果によって unpack-simple / unpack-advanced の分岐が決まります
• [[re-analyze]] の triage「サンプルにパッカーがある／アンパック」パスで呼び出します（re-anti-analysis → re-packer-id）
• [[re-malware]]：パックされたサンプルは、まずパッカーを識別してからアンパック手順を決定します
• [[re-mobile]] / [[re-apk]]：難読化対策の識別後に、パッカーの種類（Android の保護パッカー）を確認します
• [[re-triage]]：エントロピーの異常／疑わしいセクション名がある場合は、本スキルに移って確認します
• [[re-crypto-id]]：パッカー層による定数の汚染指紋。まずパッカーを識別し、アンパック後に定数テーブルのフィンガープリントを確認します
• 強力なパッカー／未知のパッカーと識別された場合 → [[re-unpack-advanced]]。単純な圧縮パッカー → [[re-unpack-simple]]。パッカーなし → [[re-binary-core]] に戻ります

常见坑与陷阱

• 签名库不全 → 漏新壳：现象——DIE/PEiD 报 "Not found"，但样本熵 7.8、导入表只有 3 个 API；原因——私有 / 小众壳不在签名库；对策——不依赖单一签名，用节名 + EP + 熵 + 导入表四特征组合判断，判定"未知壳"走手动脱壳流程
• 伪装节名：现象——节名全是 .text/.data 看不出异常，但熵高、EP 指向第二节；原因——壳故意改名节表；对策——节名只作线索不作依据，交叉验证 EP 位置 + 熵 + 导入表
• 壳套壳：现象——识别为 UPX 但 upx -d 解包后 file 仍报壳特征；原因——多层加壳（UPX 里包 Themida 等）；对策——脱一层重识别一层，逐层循环复查四要素：PE header（新 EP 位置 / 节表结构 / 头字段）、节名（是否出现新壳节特征）、熵分布（是否有新高熵节）、导入表（是否仍极小 / 只剩 GetProcAddress 动态调用）——四要素全部正常才算脱净，任何一项异常就回到本技能重跑
• 识别阶段不记 OEP 线索：现象——脱壳到一半需要"壳入口指令 / EP 地址"时手忙脚乱，断点位置全靠猜；原因——识别时没记录；对策——步骤 7 在识别阶段就记录入口指令（pushad 等）与地址，供 ESP 定律直接使用
• 识别出壳名 ≠ 壳配置全开：现象——DIE 报 VMProtect/Themida 就默认走强壳全套流程，实际样本只是简单压缩或虚拟化未启用；原因——壳名只表示"加了什么壳"，是否启用虚拟化/反调试是构建时的配置选项；对策——识别报告带上版本与配置线索（.vmp0/.vmp1/.themida 节是否存在、入口是 VM 分发型还是普通 stub、位数），交由 [[re-anti-analysis]] 决定走 [[re-unpack-simple]] 还是 [[re-unpack-advanced]] 流程
• 自动化脱壳工具对版本/位数敏感：现象——x64Unpack/Magicmida 等自动化工具对目标无效、dump 损坏；原因——脱壳器按壳的具体版本与位数实现（Magicmida 仅支持 32 位且不修 VM 反转储；x64Unpack 只验证过 Themida 2.4.6/VMProtect 3.4）；对策——识别阶段记录壳名 + 版本 + 位数（DIE 版本字段/深度扫描），选工具前核对支持矩阵，不支持就走手动流程