---
name: re-triage
description: >
  文件初步勘察：file/哈希(sha256/md5)/熵/strings/架构识别。
  触发词：先看看这文件、triage、初勘、这是什么文件、hash
capabilities: [triage]
---

# 文件初步勘察（triage）

## 何时使用 / 何时不用

- 用：刚拿到未知样本的第一步；判断文件真实类型与架构；任何分析开始前的哈希存证；熵值评估是否加壳/加密
- 不用：已确定文件类型、只需深挖结构（直接走对应格式技能 [[re-format-pe]] / [[re-format-elf]] / [[re-format-macho]]）；只需函数逻辑（走反编译技能）
- 不用：样本已确认带壳、目标直接是脱壳（走 [[re-anti-analysis]] 域）

## 工具准备

所有工具先验证再使用。参考 [[re-analyze/platform-tips]] 最高原则（静态分析可免沙箱，但涉及运行一律沙箱）。

### file —— 文件类型判定

- Linux: `apt install file` / `dnf install file` / `pacman -S file`（多数发行版自带）
- macOS: `brew install file`（自带 /usr/bin/file）
- Windows/WSL: WSL 内用 Linux 版；Windows 本机用 Git for Windows 自带 file 或第三方版
- 验证: `file --version`

### sha256sum / md5sum —— 哈希存证

- Linux: coreutils 自带（无则 `apt install coreutils` / `dnf install coreutils` / `pacman -S coreutils`）
- macOS: 自带，用 `shasum -a 256` 或 `md5`
- Windows/WSL: WSL 内 Linux 版；Windows 本机 PowerShell: `Get-FileHash -Algorithm SHA256`
- 验证: `sha256sum --version`

### strings —— 关键字符串提取

- Linux: binutils 自带（`apt install binutils` / `dnf install binutils` / `pacman -S binutils`）
- macOS: `brew install binutils`（命令带 `g-` 前缀，如 `gstrings`）或 `llvm-objdump --strings`
- Windows: Sysinternals `strings64.exe`（choco: `choco install sysinternals`），或 WSL 内 Linux 版
- 验证: `strings --version`（Linux）/ `gstrings --version`（macOS brew）

### objdump / readelf —— 架构与头信息确认

- Linux: `apt install binutils` / `dnf install binutils` / `pacman -S binutils`
- macOS: `brew install binutils`（`gobjdump`）或 `brew install llvm`（`llvm-objdump`）
- WSL: Linux 版直接可用
- 验证: `objdump -V` / `readelf --version`

### xxd —— 十六进制查看

- Linux: `apt install xxd` / `dnf install vim-common` / `pacman -S xxd`
- macOS: `brew install xxd`
- WSL: Linux 版
- 验证: `xxd -v`

### ent / python —— 熵计算

- `ent`: `apt install ent`（Debian/Ubuntu）；dnf/pacman 无官方包 → 用 python 方案
- python（跨平台兜底，推荐）: `pip install --user` 无需依赖，直接写脚本或一行命令：
  ```sh
  python3 - <<'EOF'
  import math, collections
  data = open('sample.bin', 'rb').read()
  c = collections.Counter(data); n = len(data)
  e = -sum((v/n) * math.log2(v/n) for v in c.values())
  print(f"entropy={e:.3f} bits/byte ({len(data)} bytes)")
  EOF
  ```
- 验证: 对 `/dev/zero` 输出熵 ≈ 0.000，对随机文件 ≈ 7.9+

## 操作步骤

按顺序执行，每步记下结果。

1. **file 判定格式**：
   ```sh
   file sample.bin
   ```
   记录 Magic、格式（PE32/PE32+、ELF 32/64-bit LSB、Mach-O arm64…）、架构。file 结论不可尽信——魔数可伪造，随后用 objdump 交叉验证：
   ```sh
   objdump -f sample.bin   # 打印头信息与架构
   ```
   ELF 类可加 `readelf -h sample.bin` 看 Machine 字段。

2. **哈希存证（先做再动文件）**：
   ```sh
   sha256sum sample.bin > sample.sha256
   md5sum sample.bin
   ```
   输出保存为 `sample.sha256`，写入分析笔记。之后对文件的任何修改（patch/脱壳产物）都要能与原始哈希对照。
   - **带壳样本：脱壳前记五件套基线**——确认带壳（转 [[re-anti-analysis]]）后、动手脱壳前，除 SHA256 外记录：**PE timestamp**（TimeDateStamp）、**EP RVA**（AddressOfEntryPoint）、**section hash**（各节 VirtualSize 与数据 hash）、**import table**（DLL 名 + 导入 API 清单，`objdump -p` / pefile 导出）。脱壳前后对照这份基线，是判断"是否达到可分析状态"的依据（[[re-unpack-simple]] / [[re-unpack-advanced]]）。

3. **strings 提取关键串**：
   ```sh
   strings -n 6 sample.bin | head -100
   ```
   - 找：可读文件名/URL/路径、`flag`/`key`/`secret`、错误消息（泄露内部函数名）、Go/Rust 运行时特征（`runtime.main`、`_ZN...`）
   - 中文环境：默认 `strings` 只取 ASCII；UTF-16 串用 `strings -e l sample.bin`（little-endian 16 位）；GBK 中文串先 `xxd sample.bin | head` 目测编码再决定
   - 输出巨大时先 `-n 6` 过滤短串，再配合 `grep -iE 'http|flag|key|secret|dll|\.so'`

4. **熵评估**：
   ```sh
   ent sample.bin
   # 或 python 一行脚本（见工具准备）
   ```
   - 熵 > 7.0 bits/byte：可疑加壳/加密/压缩 → 下一步按 [[re-anti-analysis]] 路径处理
   - 熵 4.5-7.0：混合内容，正常可执行文件常见区间，继续
   - 熵 < 4.5：多为明文数据/未压缩代码
   - 分节评估更准：用 `objdump -h` 或 pefile 按节算熵（壳的特征是某些节熵极高）

5. **安全特性与编译器识别**：
   ```sh
   readelf -h sample.bin | grep Type              # ET_EXEC 通常为非 PIE；ET_DYN 可能是 PIE 或共享对象
   readelf -d sample.bin | grep -i FLAGS_1        # FLAGS_1 含 PIE（DF_1_PIE）才是 PIE 可执行文件
   readelf -l sample.bin | grep -A1 GNU_STACK     # 栈含 E 权限=缺 NX
   readelf -l sample.bin | grep GNU_RELRO         # 存在=RELRO 开启（Full 再查 BIND_NOW）
   readelf -s sample.bin | grep __stack_chk_fail  # 有=canary 开启
   strings sample.bin | grep -iE 'GCC:|clang version|Microsoft Visual'  # 编译器特征
   ```
   - 编译器识别辅助后续判断：MSVC 常见 `__security_cookie`，GCC/Clang 常见 `__stack_chk_fail`（canary 形态不同）
   - 加密常量检测转 [[re-crypto-id]]（AES S-box / TEA delta 指纹）
   - 安全特性写入输出契约的 sections 摘要，供 [[re-vuln]] / 报告引用

6. **决定下一步**：
   - 正常格式 + 熵正常 → [[re-format-pe]] / [[re-format-elf]] / [[re-format-macho]]（按类型）
   - 熵异常 / 节名可疑（UPX0/.aspack）→ 转 [[re-anti-analysis]] 先确认壳
   - 目标是动态行为 → 沙箱内 [[re-tracing]] + [[re-gdb]]（见 [[re-analyze/platform-tips]] 最高原则）

7. **输出契约**：按 [[re-analyze/analysis-contract]] 输出结构化摘要——**核心字段**（target_id / sha256 / evidence / findings / unverified）+ **文件域扩展字段**（arch / format / entropy / sections / imports_exports / strings_refs / 安全特性），作为下一环节（format / 反编译 / 沙箱）的输入，不重新扫描。非文件目标（协议/模型/设备）按对应域字段出契约（见 [[re-analyze/analysis-contract]] §3.2），不套文件域字段。

## 跨域联合

- [[re-binary-core]]：工作流第 2 步固定调用本技能
- [[re-malware]] / [[re-firmware]] / [[re-mobile]] / [[re-ctf]]：各网关接手样本的第一步都是初勘
- 本技能结论（RE_TRIAGE 结果）决定后续格式技能选择，是全部动态分析前的强制前置

## 常见坑与陷阱

- **熵高 ≠ 必然加壳**：压缩数据（UPX 壳内压缩段、zlib 资源段）熵同样 >7，需结合节名与导入表判断，不要单凭熵值定性
- **strings 中文环境编码**：中文串常为 GBK 或 UTF-16LE，默认 `strings` 输出乱码/丢失——按 `-e` 参数指定编码，必要时 `xxd` 目测
- **hash 先做再动文件**：任何分析前先 sha256 存证；动态执行会污染样本文件，没有原始哈希就无法对照
- 大文件 strings 全量输出可达数百 MB → 先 `-n` 设最小长度并 `head` 截断
- **工具报错 ≠ 文件损坏**：现象——`file`/`readelf`/`objdump` 对样本报错或输出中断；原因——对抗样本伪造头字段（节头大小异常、程序头计数离谱、缺失 dynamic section）使解析器失败，并非文件真的损坏；对策——先用 `xxd` 手工核对关键头字段（e_lfanew / e_shoff / e_shnum / e_shentsize），按真实值手工修复后再解析，别把样本当垃圾丢弃
- **脱壳前不记基线 → 无法对照**：现象——脱壳后发现 EP 变了、节表增删、导入表变成动态调用，无法判断是壳的正常行为还是脱壳出错；原因——没在脱壳前记录 PE 头 / 节 / 导入表基线；对策——动手前按步骤 2 记录五件套（SHA256 / PE timestamp / EP RVA / section hash / import table），脱壳后逐项对照再判定成败
- **字符串可见 ≠ 答案（诱饵 flag）**：现象——`strings` 直接看到 flag/密钥/关键串，提交却不对；原因——高难度样本故意把诱饵放"分析师最容易看到且不会怀疑"的位置（DOS stub、资源段、明显字符串），真实答案藏在协议逻辑/加密数据里；对策——字符串只是线索不是结论，必须交叉验证（代码引用、协议逻辑、多份副本对比）；**越容易看到的位置越可疑**，尤其 DOS stub（PE 头里）出现"flag 格式"字符串基本是陷阱