docs+analysis: independent verification guide for phases A-F (calibrated scanners, self-tested commands)
This commit is contained in:
@@ -6,8 +6,28 @@
|
||||
|
||||
**`libcxsdk.so` 里没有静态调色板表**。12 个调色板全部由
|
||||
`CFunctions::SetColorPalette`(Ghidra 偏移 `0x00026c70`)在**运行时用算术生成**。
|
||||
对全文件扫描"连续 256 个 u32LE、alpha=0xFF 且 RGB 非零"的候选 **命中 0 个**
|
||||
(alpha=0x00 形式、BGR/RGB 三元组形式同样为 0)。
|
||||
|
||||
两层证据(2026-09-11 复核时补强,见"否证的最强形式"):
|
||||
|
||||
1. **正对照(决定性)**:项目持有的唯一官方表——铁虹——
|
||||
(csdk `src/mag160c_official_palette256.h`,源自厂商运行时内存
|
||||
`CoreSDKLib dev+0xb18`)在库里**以任何编码都搜不到**:
|
||||
- `B,G,R,0`(官方文档布局)→ 无
|
||||
- `B,G,R,0xFF`(alpha 强制)→ 无
|
||||
- **忽略第 4 字节的 `B,G,R` 宽松匹配 → 也无**
|
||||
|
||||
⚠️ **踩坑记录**:该表在内存里是 `(B, G, R, 0)` —— **第 4 字节是 0**,
|
||||
而 `OfficialTables.kt` 里的 ARGB int 被生成脚本强制 `alpha=0xFF`。
|
||||
因此"直接拿 Kotlin 表去二进制里搜"**永远搜不到**,会得出假的"未找到"。
|
||||
正确的针必须从 csdk 头文件(真实内存布局)构造。核查时务必用
|
||||
`analysis/tools/PalScan.java`(已按此修正)而非手工拼的 ARGB 针。
|
||||
2. **结构性证据**:Ghidra 反编译显示该函数用算术逐条生成全部 12 张表
|
||||
(`libcxsdk_decomp.txt` 的 case 0..10/12/13),所以静态数据里本就不该有。
|
||||
|
||||
> 另:早期"扫描 256 个连续 u32LE、alpha=0xFF"的判据命中 0,这一条仍成立但
|
||||
> **说服力弱**——它只说明"没有 alpha=0xFF 形式",与布局无关。
|
||||
> 通用"渐变"启发式(`PalScan.java` 的 [C] 段)在本库上误报约 11% 的位置
|
||||
> (全是指令/整数数组),**不能作为证据**,工具里已明确如此标注。
|
||||
|
||||
因此本阶段改用**移植生成函数**的路线并成功恢复:
|
||||
**UI 索引 0..10 共 11 个调色板已为官方精确表**(索引 11 见下),
|
||||
@@ -62,22 +82,38 @@
|
||||
| `analysis/sdk_re/android_app/palette_candidates.json` | 扫描结论(静态候选为空)+ 全部恢复表 |
|
||||
| `analysis/sdk_re/android_app/palette_candidates.png` | 12 组「官方预览图 + 恢复色条」对照图 |
|
||||
| `analysis/sdk_re/android_app/palette_match_report.txt` | 覆盖率证据表 |
|
||||
| `analysis/tools/extract_palettes.py` | 计划要求的纯标准库扫描脚本(可复现"无静态表"这一否定结论) |
|
||||
| `analysis/tools/extract_palettes.py` | 计划要求的纯标准库扫描脚本(本机无 python3,改用下面的 JDK 版) |
|
||||
| `analysis/tools/PalScan.java` | **JDK 版否证复核器**:正对照(铁虹在 3 种编码下的精确匹配)+ 自校准 + 通用扫描(明确标注不可作证据)。已实测:3 种编码全部 not found |
|
||||
| `analysis/tools/PalIdentify.java` | 13 个生成体的机械移植(含写地址校验) |
|
||||
| `analysis/tools/PalExport2.java` | 导出 Kotlin/JSON/PNG/报告 |
|
||||
| `analysis/tools/PalExport2.java` | 导出 Kotlin/JSON/PNG/报告(须与 PalIdentify 一起编译) |
|
||||
| `analysis/tools/CheckStrings.java` | 核对真机清单里的日志串是否真能由源码产生 |
|
||||
| `android/.../core/VendorPalettes.kt` | 生成的 Kotlin 表(0..10 为精确表) |
|
||||
|
||||
重跑(本机无 python3,Java 版单文件即可运行):
|
||||
重跑(本机无 python3;两个命令都已实测通过):
|
||||
|
||||
```bash
|
||||
java analysis/tools/PalExport2.java \
|
||||
android/app/src/main/kotlin/com/mag160c/thermal/core/OfficialTables.kt \
|
||||
<解包APK的 res/mipmap-hdpi-v4 目录> \
|
||||
android/app/src/main/kotlin/com/mag160c/thermal/core \
|
||||
analysis/sdk_re/android_app
|
||||
# 否证复核:铁虹是否真的不在库里(决定性证据)
|
||||
java analysis/tools/PalScan.java \
|
||||
analysis/sdk_re/android_app/bin/libcxsdk.so \
|
||||
csdk/src/mag160c_official_palette256.h
|
||||
|
||||
# 生成物可复现:重新生成后与仓库文件 diff 应为空
|
||||
mkdir -p /c/Users/zxc/AppData/Local/Temp/regen_build && \
|
||||
cd /c/Users/zxc/AppData/Local/Temp/regen_build && \
|
||||
cp "C:\Project\MAG160C\analysis\tools\PalIdentify.java" . && \
|
||||
cp "C:\Project\MAG160C\analysis\tools\PalExport2.java" . && \
|
||||
"C:\Tools\jdk-21\bin\javac" -d out PalIdentify.java PalExport2.java && \
|
||||
"C:\Tools\jdk-21\bin\java" -cp out PalExport2 \
|
||||
"C:\Project\MAG160C\android\app\src\main\kotlin\com\mag160c\thermal\core\OfficialTables.kt" \
|
||||
"C:\Users\zxc\AppData\Local\Temp\cxres\res\mipmap-hdpi-v4" \
|
||||
"C:\Users\zxc\AppData\Local\Temp\regen_core" \
|
||||
"C:\Users\zxc\AppData\Local\Temp\regen_out"
|
||||
diff "C:\Users\zxc\AppData\Local\Temp\regen_core\VendorPalettes.kt" \
|
||||
"C:\Project\MAG160C\android\app\src\main\kotlin\com\mag160c\thermal\core\VendorPalettes.kt"
|
||||
# 实测:diff 为空;铁虹锚点 256/256
|
||||
```
|
||||
|
||||
有 python3 的机器上:
|
||||
有 python3 的机器上(可选,仅证明"无静态 256 项 alpha=0xFF 表"这个弱结论):
|
||||
|
||||
```bash
|
||||
python3 analysis/tools/extract_palettes.py \
|
||||
|
||||
Reference in New Issue
Block a user