re-binary-core

软件逆向核心

完整工作流

1. 环境：探测 + 偏好（若未走 [[re-analyze]] 入口，先补做，读取 RE_* 会话变量）
2. 初勘：[[re-triage]]（能力：triage） —— file/hash/熵/strings，确认文件类型与架构
3. 格式解析：按类型走 [[re-format-pe]]（能力：pe-parser） / [[re-format-elf]]（能力：elf-parser） / [[re-format-macho]]（能力：macho-parser）
4. 导入导出：[[re-imports]]（能力：pe-parser、elf-parser） —— 库指纹、IAT/符号，识别链接了什么
5. 反编译：按 RE_DECOMPILER 走 [[re-ghidra]]（能力：decompilation、debugging） / [[re-ida]]（能力：decompilation、debugging） / [[re-radare2]]（能力：decompilation；未装 → 按对应技能「工具准备」安装；默认推荐 Ghidra）
6. 动态（按需，默认沙箱）：[[re-gdb]]（能力：debugging） / [[re-x64dbg]]（能力：debugging） / [[re-lldb]]（能力：debugging；按 OS）+ [[re-tracing]]（能力：tracing） + [[re-memdump]]（能力：memory-dump）
7. 产出：结论 / 报告（按 RE_REPORT）

分析方法论

本网关适用的通用分析方法论（用户实战经验），各技能坑与陷阱引用此处。

入口分析

• R1 入口点≠main：EP 是初始化入口，经 CRT/TLS/loader 才到 main
• R2 字符串交叉引用优先于函数猜测：关键字符串→XREF 回溯
• R3 没有字符串≠没有逻辑：编码/哈希/运行时拼接/解密生成，追踪使用点
• R4 函数边界异常→检查反编译假象：手写汇编/混淆/尾调用/无 frame pointer，不完全相信 decompiler

调用分析

• R5 call 很少≠逻辑简单：函数指针/虚表/回调/切换跳表间接调用
• R6 间接调用异常→查函数指针来源：追踪寄存器/内存中目标地址来源
• R7 虚函数分析→先找 vtable：对象指针→vptr→vtable→函数集合

内存与数据结构

• R8 结构体识别不要只看字段访问：结合初始化位置/生命周期/多处使用
• R9 malloc/free 跟踪对象生命周期：创建点和释放点定含义
• R10 全局变量先找引用不找定义：全局区噪声高

API/行为

• R11 API 调用只是结果不是逻辑：分析参数来源和调用上下文
• R12 异常处理可能是控制流：SEH/C++ exception/signal handler 承担正常跳转
• R13 系统调用层比 API 更可信：hook/封装/替换时向下追到 syscall

混淆分析

• R14 控制流平坦化→看状态变量：调度器+状态变量+情况块
• R15 垃圾代码比例高→不逐条分析：找外部影响/数据流/真实调用
• R16 opaque predicate→验证条件是否恒定：永真/永假判断

动态调试

• R17 断点失效→不一定没执行：自修改代码/内存重映射/异常机制/反调试绕过
• R18 单步异常→查反调试：陷阱旗/时间检测/异常处理
• R19 看见解密数据→立刻保存：下一阶段可能清除

PE/ELF 深层

• R20 内存布局比文件布局重要：loader 后的映射状态才是运行时真相
• R21 section 名称不可信：看权限/熵/内容
• R22 重定位信息影响 dump：地址不一致时先查 relocation

情报与初勘

• R23 三表先行：file（格式）→ 分区熵（代码/数据/密文分布）→ strings（宽窄字符都要扫，壳会转宽字符串）——任何深挖之前这三步做完，避免 80% 的方向性错误
• R24 熵要分区采样：整体 4KB 熵 7.9 ≠ 全部密文——入口区 64B 熵 5.6 可能是真代码；用 64B/1KB 窗口扫描找明文/密文边界；高熵≠加密：可能是压缩、VMProtect 变异、或数据，判断加密前先排除压缩与混淆
• R25 导入表两面性：(a) 导入表极小（几个函数）= 壳/动态解析信号；(b) 死导入：IAT 有桩但 .text 零调用点 = LoadLibrary+GetProcAddress 动态加载，静态导入结论作废（c) 导入表数字≠API 面：COM 接口（d3d11 等）1 个导入背后几百个 vtable 方法，真实调用面永远在导入表之外
• R26 构建路径/日志函数名是最强情报：G:\BuildAgent\...\Graphics_Renderer_D3D11.cpp 泄露整个渲染器架构；Renderer::CreateAdapter() 还原初始化链——优先于函数猜测

反汇编方法

• R27 线性反汇编必漂移：PE 代码节内嵌跳转表，从节头顺序解码到中段全是垃圾；免疫方案 = 逐字节模式扫描（只认 FF15/FF25 call/jmp [rip] 与 8B/8D mov/lea [rip] 模式，目标地址用原始字节算 next_ip + disp32，不用解码器的 displacement 字段）
• R28 反编译器卡死果断降级：密文/混淆区当代码做函数分析会指数爆炸（4 核转 8 分钟）——限制分析范围（-analysisTimeoutPerFile）或换手写解码器，别等
• R29 工具盲区交叉验证：objdump 对异常节标志（MEM_NOT_PAGED）静默跳过、iced-x86 的 RIP 相对 displacement 返回非裸值、readelf 对伪造头报错中断——每个工具都有盲区，两个独立工具解析同一数据，不一致就是有问题
• R30 入口字节判真伪：e8 xx xx xx xx（call）+ 0f 05（syscall）看着像代码也可能是随机巧合——顺序解码跟 30 条，出现 fcom/int 88h/ret far 类指令即为假

验证

• R31 静态结论必须动态背书："能跑"≠"正确"（重定位正确性只有运行时读内存槽位能证明）；逐字节验证只能证明"实现符合规格"，证明不了"规格正确"——动态侧从活内存读槽位与文件存储值比对
• R32 两个独立工具解析同一数据：addend 对照文件存储值、符号地址对照 nm 输出、RVA 对照 objdump——不一致就是有问题，别信单一工具输出
• R33 动态最小侵入：DLL 劫持代理（记录调用序列）> 调试器 > 插桩框架；能不改目标二进制就不改；动态分析一律沙箱（firejail/bwrap + 无网络 + 一次性环境）

知识获取

• R34 格式偏移查规范，不凭记忆：PE32+ 数据目录在 oh+112（+96 是 SizeOfHeapCommit）、TEB 偏移等字段类知识——凭记忆必错，MS 规范/ELF gABI 是唯一权威（具体值见 [[re-format-pe]]/[[re-format-elf]] 领域经验）
• R35 开源实现是第二权威：TEB 布局查 Wine winnt.h、系统调用语义查 ReactOS 源码——比博客可靠，且可交叉验证

どのアトミックスキルを使うか（選択ツリー）

• ファイルを受け取ったばかりで、種類がわからない → [[re-triage]]（能力：triage）
• PE / ELF / Mach-O と判明しており、構造を理解したい → 対応する形式スキル
• プログラムがリンクしているライブラリ/APIを知りたい → [[re-imports]]（能力：pe-parser、elf-parser）
• 関数のロジックを読み解きたい → 逆コンパイルから選択（[[re-ghidra]]（能力：decompilation、debugging）がデフォルト；[[re-ida]]（能力：decompilation、debugging） / [[re-radare2]]（能力：decompilation） / [[re-binaryninja]]（能力：decompilation））
• 実行時の動作を確認したい、ブレークポイントを設定したい → OSに応じてデバッガーを選択（Linux [[re-gdb]]（能力：debugging）、Windows [[re-x64dbg]]（能力：debugging） / [[re-windbg]]（能力：debugging）、macOS [[re-lldb]]（能力：debugging））
• システムコール／関数呼び出しを追跡したい → [[re-tracing]]（能力：tracing）
• プロセスメモリを読み取り／ダンプしたい → [[re-memdump]]（能力：memory-dump；デフォルトではダンプを優先。[[re-analyze/platform-tips]]を参照）
• 対象がドライバー／カーネルモジュール／rootkit → [[re-kernel]]（能力：kernel-analysis；カーネルデバッグには[[re-windbg]]（能力：debugging）を併用）
• 対象がhypervisor/VMM／仮想化検出関連 → [[re-hypervisor]]（能力：hypervisor-analysis；VT-x/SVM、VMCS/EPT）
• 対象がアンチチートコンポーネント（EAC/BattlEyeドライバー、メモリ整合性チェック）→ [[re-anti-cheat]]（能力：kernel-analysis；ドライバー分析＋カーネルデバッグ。認可範囲に注意）
• 対象環境がなく、アンパックを補助するためにエミュレート実行が必要 → [[re-emulation]]（能力：emulation）
• 対象がshellcode（ファイル形式ヘッダーのない生のコードblob：抽出／デコードループ／エミュレート実行）→ [[re-shellcode]]（能力：shellcode-analysis）
• 対象がゲーム（Unity/Unreal、CEによるメモリ改変）→ [[re-game]]（能力：game-analysis）
• 対象がGoバイナリ（言語固有の分析：シンボル／文字列テーブル／goroutine）→ [[re-go]]（能力：lang-runtime-analysis）
• 対象がRustバイナリ（言語固有の分析：シンボル解釈／ジェネリック展開／所有権）→ [[re-rust]]（能力：lang-runtime-analysis）
• 対象がC++（RTTI／例外テーブルが大量にある） → [[re-cpp-abi]]（能力：decompilation；RTTI／仮想テーブル／例外の復元）
• 対象がSwift生成物（$s manglingの特徴がある） → [[re-swift]]（能力：lang-runtime-analysis；mangling／witness table／クロージャキャプチャ）
• 対象がZig生成物（RTTI／例外テーブルがなく、panic関数の特徴がある） → [[re-zig]]（能力：lang-runtime-analysis；comptime／エラーパス）
• 対象がNim生成物（NimMain/NimStringの特徴がある） → [[re-nim]]（能力：lang-runtime-analysis；ランタイム／文字列構造）
• 対象がHaskell/OCaml生成物（GHC RTS/OCaml blockの特徴がある） → [[re-fp-runtime]]（能力：lang-runtime-analysis；クロージャ／データフロー）
• パッチ／N-dayの比較（修正前後／亜種の関連付け） → [[re-variant]]（能力：binary-diffing；関数マッチング／パッチdiff）
• Ghidra/IDAのスクリプトやプラグインを書きたい（一括注釈／復号ループ／カスタム形式の解析、スクリプトからプラグインプロジェクトへの拡張）→ [[re-plugin-dev]]（能力：plugin-development）
• パックされている疑いがある → [[re-anti-analysis]]（能力：unpack、deobfuscation、evasion-analysis）へ進む

クロスドメイン連携

• [[re-mobile]]：モバイルアプリのネイティブ.soライブラリ分析 → このゲートウェイの[[re-format-elf]]＋[[re-ghidra]]（専門分野は[[re-android-native]]を参照）
• [[re-hypervisor]] / [[re-anti-cheat]]：hypervisorとアンチチートドライバーのリバースエンジニアリング分析では、このゲートウェイのスキルを基盤として使用（[[re-kernel]] / [[re-windbg]]によるカーネルデバッグ）
• [[re-ctf]]：CTFのリバースエンジニアリング問題 → このゲートウェイのスキルを基盤として使用
• [[re-anti-analysis]]：静的分析で難読化／パッカーを発見 → アンパック分野へ移行
• [[re-shellcode]]：shellcodeペイロードの専門分析（抽出／デコード／エミュレート実行）→ 逆コンパイルの基盤にはこのゲートウェイのスキル（[[re-radare2]] / [[re-ghidra]]）を使用
• このゲートウェイのスキルは、[[re-malware]]の詳細なリバースエンジニアリング工程で参照されます

よくある落とし穴と注意点

• メモリが<4GBと検出されてもGhidraを選ぶ → [[re-radare2]]を提案
• stringsの出力が暗号化／圧縮の影響を受けている → エントロピー（re-triage）を使って、先にアンパックすべきか判断
• /proc/<pid>/memを直接読む前に、必ずmapsを確認（[[re-analyze/platform-tips]]を参照）

未知の形式とエミュレート実行

• 未知の形式や独自改変された形式では、手作業で解析せず、対象自身のパーサーに答えさせる：現象——独自改変されたバイトコード／リソース／プロトコル形式を手書きで解析し、何度も位置がずれる；原因——対象ベンダーが形式を変更しており、公開ドキュメントと実装に食い違いがある；対策——対象内でその形式を読み込めるコンポーネント（組み込みVM、解析ライブラリ）を探し、それを使って「コンパイル／読み込み／エクスポート」し、同じ環境で生成された成果物を得る（例：対象付属のLua VMで対象のバイトコードをコンパイルする）。形式互換性の問題をなくす——「動かせるならリバースエンジニアリングしない」という汎用的な考え方
• 関数をエミュレート実行する前に、依存関係を見極める：現象——エミュレーターで関数を呼び出すと、メモリ未マップ／範囲外のエラーが発生する；原因——関数がモジュールの静的領域／グローバル状態を参照しており、マップ範囲を超えている；対策——検証対象には、グローバル依存のない純粋な計算関数（静的getter、パッカー／アンパッカー）を優先する；グローバル状態が必要な関数では、参照アドレスに従ってメモリマッピングを補完してから呼び出す
• パッチスクリプト形式のリソース：対象のコンパイルパイプラインで同じ構造の成果物を生成する：現象——サードパーティのコンパイラー／パッカーで生成したバイトコードやリソースを対象が読み込めない、または動作に異常がある；原因——コンパイラーのバージョン／設定が対象と一致していない；対策——対象付属のコンパイル／パッケージ機能（エクスポートされたコンパイルAPI、dump系関数）を優先して使い、パッチ成果物を生成する
• バイト配置はすべてスクリプトで解析し、アサーションを使う：現象——手作業でhexのオフセットを数えると全体がずれる（マジックナンバーの長さを誤る、フィールドのオフセットが1ずれる）；原因——目視でのオフセット計算は信頼できない；対策——スクリプトでヘッダー／フィールドを解析し、アサーションで検証する；パーサーの出力とツールが食い違う場合は、まずツールが想定どおり動作しているか確認する（エイリアス／ラッパー／引数によって動作が変わることがある。例：grepのラッパーがバイナリ内容をスキップする）
• 間接ジャンプで平坦化されたメイン関数：現象——逆コンパイラーが関数前半のCFGしか認識せず、ディスパッチャーの位置で止まる；原因——間接BRジャンプテーブル（制御フローの平坦化）；対策——ジャンプテーブルの式target = (table_entry + fixed_delta)に基づいて実際の基本ブロックを列挙し、デフォルトのCFGに依存しない；シンボルの長さがCFGで認識された長さを大幅に超える場合は、BR/BLR間接テーブルを優先して調べる
• 関数ごとのXOR文字列復号器：現象——文字列スキャンで少数のパスしか確認できない；原因——テキストが文字列ごとに独立したループXORで暗号化されている；対策——「先頭Nバイトの鍵＋後続Mバイトの暗号文」という配置を特定し、復号器の命令から鍵／出力の長さを抽出して、アルゴリズムを静的に再実行する（平坦化されたブロックで局所的な定数伝播を行うだけで、間接ジャンプ先と文字列のソースアドレスを復元でき、事前に完全な平坦化解除を行う必要はない）
• 自己解凍アーカイブを安全に展開する：現象——展開対象に悪意のあるパスが含まれている；原因——アーカイブ内のパスは細工できる；対策——メンバーごとに検証してから書き出す（絶対パス、..、リンク、デバイスノードを拒否する）。直接実行せず、メンバーのパスを信用しない
• 圧縮ペイロードの特定：現象——マジックナンバーだけで圧縮ストリームを探すと見落としがある；原因——マジックナンバーが一意ではない／難読化されている；対策——候補オフセットで完全な展開テスト（有効なストリームかの検証）を行い、ヘッダーだけを見ない （出典：reverse-skill field-journal、MIT）