# Native / Activity 业务突破验证

- 日期：2026-06-10
- 状态：active
- 范围：Categorizr: Receipt Scanner、Background Eraser、Image to PDF Converter
- 模式：deep/native proof-of-capability
- 原始工具输出：`data/extracted/package_forensics/runs/20260610-native-product-breakthrough/`

## 总结论

1. Native 线可以真实推进，不只是看库名：Ghidra headless 已对 4 个业务相关 `.so` 跑通，并生成 `ghidra-native-summary.json`。
2. 最有突破价值的是带业务 JNI 符号的库。Background Eraser 的 `liberaser.so` 直接恢复出 `EraserActivity_nativeAuto`、`EraserActivity_nativeMagic`、`FeatherActivity_nativeClip1Px`、`FeatherActivity_nativeRemoveSpike`、`FeatherActivity_nativeSmooth`，可以把产品工具和 native 函数直接对应。
3. 第三方 native 库能证明能力边界，但不等于业务逻辑。Categorizr 的 `libsmart_cropper.so` 主要暴露 OpenCV/TBB 符号，`libtensorflowlite_jni.so` 主要是 TFLite JNI；它证明文档裁剪/视觉模型栈存在，但评分、OCR、收据分类、账号和导出流程仍在 Java/Kotlin 或远端。
4. 轻量工具 native 库常只承担局部图像处理。Image to PDF Converter 的 `libphotoprocessing.so` 能看到 `njInit`、`njDecode`、`njGetWidth`、`njGetHeight` 等 JPEG 解码/图像处理函数；PDF 生成/页面流还要回到 Activity/smali 层。
5. Native deep 的下一步不是盲目跑所有 `.so`，而是先按 Activity 和 library name 定点：业务 JNI > 自有图像/AI/processing 库 > 模型桥接 > 第三方框架库 > 广告/加固库。

## 样本结果

| App | Activity 反推 | Native/Ghidra 结果 | 能突破到哪里 | 下一步 |
|---|---|---|---|---|
| Background Eraser | `AlbumListActivity` -> `CropActivity` -> `EraserActivity` / `FeatherActivity` -> `SaveActivity` | `liberaser.so` 有业务 JNI：`nativeAuto`、`nativeMagic`、`nativeClip1Px`、`nativeRemoveSpike`、`nativeSmooth`；还包含授权/签名校验 `isAuthorized` | 可以把“自动擦除/魔法擦除/边缘羽化/去毛刺/平滑”等产品工具映射到 native 函数，并读到部分像素/alpha 处理逻辑 | 用 smali 找这些 JNI 调用点和参数含义；真机录屏验证工具顺序和免费/广告限制 |
| Categorizr: Receipt Scanner | 70 个 first-party Activity，覆盖 `CameraActivity`、`AddExpense`、`AddStore`、`AddCategory`、`CreateAccount`、`AddInsurance` 等 | `libsmart_cropper.so` 主要是 OpenCV/TBB；`libtensorflowlite_jni.so` 主要是 TFLite JNI；包内还有 PDFium、TIFF、smart cropper | 能确认“收据拍摄/文档裁剪/本地视觉模型/PDF 渲染”能力栈，但不能直接还原收据分类业务状态机 | smali 搜 `System.loadLibrary`、`smart_cropper`、TFLite model 路径；动态拍一张收据抓 OCR/分类请求 |
| Image to PDF Converter | `MainActivity`、`CreatePDFActivity`、`OpenPDFActivity`、`PDFFilesActivity`、`RemoveAdsActivity`、`SettingActivity` | `libphotoprocessing.so` 暴露 `njInit`、`njDecode`、`njGetWidth`、`njGetHeight`；包内还有 PDFium 和 image processing JNI | 能确认本地图片解码/处理和 PDF 预览/渲染栈；产品主流程基本在 Java/Kotlin Activity | smali 追 CreatePDFActivity 的图片排序、压缩、PDF 写入和 RemoveAds 触发点 |

## 对 quick/deep 模式的沉淀

### Quick 模式适合做什么

- 50-200 个样本快速归类：产品类型、交互路径、变现、技术栈、可复刻点。
- 根据 `analysis.json` + `activity-triage.json` + 可选 Flutter/Hermes/native 摘要打出深挖优先级。
- 找“低垂果实”：本地 PDF、扫码、cleaner、GPS camera、简单 photo editor。

### Deep 模式怎么加入

1. **Flutter deep**：blutter 摘要 + 人工状态机，抽 route、Remote Config、接口、paywall、广告点位。
2. **Hermes deep**：反编译 JS bundle，抽 navigation、API client、store、feature flag、paywall 文案。
3. **Native deep**：Activity triage 选业务 `.so`，Ghidra 跑 JNI/函数摘要，smali 找调用点。
4. **Dynamic deep**：真机录屏 + MITM/HAR + Frida hook Remote Config/Billing/OkHttp/JNI，确认静态推断。

### Native 静态止点

- Ghidra 能读到函数名、JNI 名、部分 decompile preview，但不能自动知道按钮文案、页面顺序和业务触发条件。
- 第三方库如 OpenCV、TFLite、PDFium 只能证明能力存在，不能证明产品流程或服务端策略。
- 若符号被 strip 或逻辑被混淆，必须靠 smali 调用点、动态 hook 和输入/输出样本补齐。