Xigong Funk Hikari

---
name: xigong-funk-hikari
description: Evidence-driven Hikari-LLVM/OLLVM deobfuscation and plaintext recovery for ELF/SO, especially Android/Linux AArch64 PIE executables that use MBA, BCF/opaque predicates, relocation-backed BR/BLR dispatch, function wrappers/FCO, runtime string decoding, high-entropy containers, flat anonymous RX/RO/RW inner images without a primary ELF magic, embedded auxiliary ELFs, and custom mmap/mprotect loaders. Use when the user asks for Hikari identification, complete deobfuscation, lossless plaintext restoration, searchable strings, runtime payload dumping/rebuilding, an IDA-ready inner ELF, a directly runnable plaintext-bearing single file, or a loader-free rebuild. Produces hash-bound layer artifacts, reversible register-preserving patch manifests, runtime materialization evidence, and structure/semantic/runtime/equivalence verification.
x-alice-class: assist
---

# 西宫-FUNK-Hikari

## 目标优先级

默认把“明文”理解为最终目标，不在外层控制流改写后停止。先确定交付等级：

| 等级 | 产物 | 可搜索明文 | 可直接运行 | loader-free |
|---|---|---:|---:|---:|
| L1 | 外层静态反混淆 ELF | 不保证 | 是 | 否 |
| L2 | 内层原始内存镜像 + 分析 ELF + 字符串池 | 是 | 否 | 否 |
| L3 | 明文承载型单文件 ELF carrier | 是 | 是 | 否 |
| L4 | 重建 imports/relocations/TLS/entry 后的单层 ELF | 是 | 是 | 是 |

用户说“明文，最好直接运行”时默认完成 L3；用户明确要求“去掉外层/单层/不再经过 loader”时才以 L4 为完成条件。L3 必须明确执行仍由原 loader 驱动，不能称为单层重建。

## 不变量

1. 原样本只读；每个外层、dump、归一化镜像、分析 ELF、carrier 和 patch 产物分别记录 SHA-256。
2. 地址写成 `artifact_sha256 + address_space + VA/file_offset`。运行时地址另带 PID、采集时机、mapping 和 load bias；`post_load_tail` 与 true overlay 分开记录。
3. 外层 materialization 与内层 Hikari semantics 分账。分析时分层，交付时可以合并为一个 carrier。
4. family marker 只证明 provenance；每个 MBA/BCF/CFF/indirect/string/wrapper pass 仍须独立闭合 `input -> transform -> output -> consumer` 合同。
5. 只改写已证明的静态 target。依赖运行寄存器、索引、线程状态或输入的 `BR/BLR` 保留并映射，禁止为追求数量硬编码。
6. `inner.raw.mem` 保持捕获字节不变；指针归一化只进入 `inner.analysis.elf`，二者不得混称无损原像。
7. analysis ELF 不等于 executable。缺少可信 entry/dynamic/import/relocation/TLS/constructor 时，禁止称其可运行。
8. 所有修改都有 expected bytes、allowlist diff、rollback 和行为回归。宿主控制台乱码不能替代原始 stdout/stderr 字节判断。

## 工作流

### 0. 建档与基线

创建独立 case，记录原样本 hash、ELF 头、PHDR、sections、`post_load_tail`、true overlay、`.comment`、imports、relocations 和入口。以 `represented_end=max(EHDR/PHDR/非 NOBITS section/SHDR file ranges)` 计算 overlay；合法 section/SHDR 尾部不修复、不截断。对至少两类输入保存原始 stdout、stderr、退出码与超时状态：正常/失败输入和 EOF；交互程序保持 stdin writer 打开，避免把 EOF 自动退回误判为真实路径。

### 1. 识别与排他

运行静态 triage：

```powershell
python <skill-root>\scripts\hikari_static_rewrite.py SAMPLE --inspect --report-dir CASE\reports\triage
```

同时检查 `.comment` 中 Hikari/LLVM provenance、AArch64 relocation-backed code pointers、`BR/BLR` 密度、二项 selector、wrapper cluster、MBA 指令密度、opaque predicate、runtime decoder 和匿名执行信号。不得用高熵、复杂 CFG、单个 marker 或 `memfd` 单独证明 Hikari/CFF/VM。详细判定读 `references/identification-and-routing.md`。

按证据组合复用现有能力：AProtect/MSFT profile 优先交给 `$a-protector-elf-repair`；fake PT_LOAD/entry translation 交给 `$linker-fake-load-unwrapper`；Android 匿名 RX/memfd dump 与短窗口捕获可结合 `$android-elf-runtime-dump`；函数边界、xref 和 microcode 交给 `$ida-reverse`；超出本工具闭合形态的 CFF/BCF/VM 回到 `$xigong-auto-reverse`、其内置 OLLVM provider 或 `$vm-and-bytecode-reverse`。这些 provider 的输出都要重新绑定当前 artifact hash，不能搬用旧地址。

### 2. 外层语义保持改写

先用 IDA 批量导出函数边界；可选叠加 perf/runtime offset。对 ELF64 LE AArch64 的 relocation-backed dispatcher 使用：

```powershell
python <skill-root>\scripts\hikari_static_rewrite.py SAMPLE `
  --ida-functions CASE\reports\ida_functions.csv `
  --perf-samples CASE\reports\perf_offsets.txt `
  --out CASE\artifacts\outer.deobf.elf `
  --report-dir CASE\reports\outer_deobf
```

工具只把闭合 target 的 `LDR pointer + BR/BLR` 和已证明二项 selector 改成直接边，保留动态边并生成 `unresolved_indirect.json`。若 patch 后崩溃，把新增 patch 按组做二分 ablation；每轮只改变一个 patch 集，接受条件是基线字节级等价。详细算法读 `references/outer-static-deobfuscation.md`。

### 3. 明文充分性门禁

外层改写后立即执行以下判据：

```text
已知运行时提示/业务词在文件中不可搜索
OR 运行 pc/lr/关键字符串 consumer 落在匿名 RX、memfd 或新映射
OR 磁盘 ELF 的函数/字符串规模明显小于运行时业务规模
=> materialization = RUNTIME_REQUIRED；禁止声称“彻底明文化”
```

这一步用于纠正最常见误判：控制流反混淆成功不代表明文 payload 已经物化。

### 4. 定位并捕获 active inner

在正确 PID 和业务阶段保存 `/proc/PID/maps`。通过 loader handoff、关键 PC/LR、输出 backtrace 或字符串地址确定 inner cluster；不要按“最大匿名段”猜测。捕获 cluster 内全部可读映射并保留权限与空洞：

```powershell
python <skill-root>\scripts\hikari_runtime_image.py capture `
  --serial SERIAL --pid PID --range 0xSTART:0xEND `
  --out-dir CASE\runtime\inner_capture
```

同一阶段至少捕获两次；比较 mapping layout、hash 和字符串命中，确认不是临时 allocator 噪声。短生命周期程序在 prompt/loader handoff 后冻结或用 FIFO 保持输入窗口。详细流程读 `references/runtime-materialization.md`。

用 `hikari_runtime_image.py compare-captures CAPTURE_A CAPTURE_B --out REPORT.json` 做逐 mapping 完整性比较。Flat inner 可以没有 offset-0 ELF magic；其内部命中的 ELF 只列为 auxiliary candidate，不能替代 handoff/active-PC 证明。Custom mapper/high-entropy container 的完整判定读 `references/flat-inner-custom-loader.md`。

### 5. 重建 raw image 与分析 ELF

```powershell
python <skill-root>\scripts\hikari_runtime_image.py rebuild `
  CASE\runtime\inner_capture --base 0xSTART --end 0xEND `
  --out-prefix CASE\artifacts\inner.plain --normalize-pointers

python <skill-root>\scripts\hikari_runtime_image.py strings `
  CASE\artifacts\inner.plain.mem --base 0 `
  --out-prefix CASE\reports\inner_plain_strings
```

保留三份语义不同的对象：capture segments、相对布局 raw memory、指针归一化 analysis ELF。`rebuild` 输出 `embedded_elf_candidates`，但主 inner 身份仍由 handoff/PC-LR 证明。默认字符串提取只接受完整 UTF-8 NUL token 以压低噪声；目标确有 UTF-16LE 时显式添加 `--encodings utf-8,utf-16le --mode scan` 并用 consumer/xref 过滤。用 readelf/IDA 检查 PT_LOAD 权限、地址间隔、函数和 xrefs；不要因为 synthetic ELF 可解析就给它伪造 entry。

### 6. 打磨可运行明文交付

L3 保留已验证可运行的 outer prefix，把 raw inner image和带 hash 的 trailer 追加为 overlay：

```powershell
python <skill-root>\scripts\hikari_runtime_image.py carrier `
  CASE\artifacts\outer.deobf.elf CASE\artifacts\inner.plain.mem `
  --runtime-base 0xSTART --runtime-end 0xEND `
  --output CASE\artifacts\plain.runnable.elf `
  --manifest CASE\reports\plain_runnable_manifest.json

python <skill-root>\scripts\hikari_runtime_image.py verify-carrier `
  CASE\artifacts\plain.runnable.elf `
  --manifest CASE\reports\plain_runnable_manifest.json `
  --needle "请输入" --needle "版本"
```

Carrier 必须满足：outer 前缀逐字节不变、payload hash 一致、目标明文直接可搜索、ELF parser 仍通过、Android/Linux 直接执行等价。L4 的 dynamic/import/entry/TLS/constructor 重建和 handoff 替换读 `references/runnable-delivery.md`；没有这些证据时保持 L3，不伪装为 loader-free。

### 7. 五轴回归

对 root、outer deobf、carrier 分别运行：

```powershell
python <skill-root>\scripts\hikari_equivalence.py adb `
  --serial SERIAL --root SAMPLE --candidate CASE\artifacts\plain.runnable.elf `
  --case dummy=TEST-KEY --eof --out CASE\reports\equivalence.json
```

必须报告：

- structure：ELF/PHDR/sections、patch 指令反汇编、overlay 不破坏 loader；
- semantics：每类 pass 的 closed contract、未解析动态边、inner provenance；
- runtime：每个输入 stdout/stderr/rc/timeout；
- packaging：权限、ABI、签名/加载方式、单文件结构；
- equivalence：非目标路径、EOF、writer-open、异常输入和 rollback。

最终回归矩阵和 failure fingerprint 读 `references/validation-and-corrections.md`。

## 产物布局

```text
CASE/
  case.json
  artifacts/
    outer.deobf.elf
    inner.plain.mem
    inner.plain.analysis.elf
    plain.runnable.elf
  runtime/inner_capture/{maps.txt,capture.json,*.bin}
  reports/
    triage.json
    patch_manifest.json
    unresolved_indirect.json
    inner_plain_strings.{json,tsv,txt}
    plain_runnable_manifest.json
    equivalence.json
    FINAL_REPORT.md
```

报告模板位于 `assets/final-report-template.md`。只把已证明结论写成完成项；L1/L2/L3/L4 必须明确标注。

## 按需读取

- 识别、false-positive gate、pass 路由：`references/identification-and-routing.md`
- AArch64 relocation dispatcher、patch transaction、ablation：`references/outer-static-deobfuscation.md`
- Android 匿名 inner 定位、dump、镜像重建：`references/runtime-materialization.md`
- 高熵容器、custom mapper、flat inner、嵌入 ELF 与寄存器 patch：`references/flat-inner-custom-loader.md`
- L3 carrier 与 L4 loader-free 重建边界：`references/runnable-delivery.md`
- 本次错误纠正、回归矩阵和 failure fingerprints：`references/validation-and-corrections.md`

依赖：Python 3.10+；静态改写需 `capstone`，动态设备通道需 `adb` 和可读取 `/proc/PID/mem` 的权限；IDA exporter 在 IDAPython 中运行。