【开源深度评测】NOIR：权限、端点和回滚记录，怎样变成一份可解释的 Android 报告
专栏标签：#开源评测 #Android安全 #APK静态审计 #移动安全 #L3静态取证
评测体系：Valhalla SafeNet Accelerator × Matrix Alchemy Lab｜L3 有界静态取证
取证快照：2026-11-05｜固定 commit：7b14d6c6ac751b291df3936844aa6291d3790fb5
仓库地址：https://github.com/Verlintas/NOIR
许可：MIT｜累计Stars：2326（API快照）
作者：Valhalla Matrix治理实验室
⚠️ 重要声明：本文为L3静态证据评测，未连接Android设备、未执行ADB指令、未扫描真实APK、未验证权限变更与回滚流程；仅基于固定快照内选定文件做结构与词法证据复核。L3仅代表证据链路可追溯，不等于分类结果准确、操作可逆、工具本身安全。
摘要：Android 安全排查里，权限清单、App包名、内置网络端点是最基础的线索，但这些信息分散在Manifest、资源、二进制字符串中，很难形成一份可解释、可落地的调查清单。NOIR 面向已授权设备，将静态权限、通信端点、厂商归类、风险关联、处置方案整合为结构化审计报告。它最核心的价值不是自动判定恶意软件，而是把“静态线索”做成带边界说明的调查优先级清单。本文基于冻结快照，从厂商归因、数据暴露关联模型、回滚测试规范、离线安全边界完整拆解，同时厘清静态分析的天然局限与落地校验方案。
一、背景：Android静态审计的常见误区
很多移动安全小工具容易走向两个极端：
要么只罗列一堆原始权限、域名，没有归类，审计人员需要手动梳理；
要么直接给一个风险打分，暗示“这个App在偷数据”，混淆静态关联和真实流量行为。
静态信息只能证明：App拥有某项权限 + 代码里存在某个目标域名；
不能直接证明：权限已经被调用、数据已经发送到该域名。
NOIR 的设计思路，就是守住这条边界：
它不做自动裁决，而是把分散线索标准化、可解释化，附带处置动作和回滚记录，给安全人员提供调查入口。
本次评测来源：近7天新建仓库按累计Stars冻结搜索快照第10位，不属于GitHub Weekly Trending榜单，文中不做周榜宣传。
二、核心设计：四层模型，把审计线索结构化
2.1 分类器Classifier：先包名规则，再域名线索，规避误判
Classifier 的归因逻辑有明确先后顺序：
- 优先基于包名前缀规则做厂商识别；
- 再提取域名线索辅助归因；
- 内置过滤规则，剔除Android通用基础设施域名，避免把系统公共域名误判为第三方厂商通信地址。
✅ 优势：规则透明、可解释，审计人员可以追溯每一条归因来自哪条规则；
⚠️ 局限：包名改版、SDK共用、域名变更都会造成归因漂移；分类结果不能当作恶意判定、取证结论或法律依据。
快照参考文件：
core/src/commonMain/kotlin/app/noir/core/Classifier.kt
2.2 Exposure 暴露模型：表达关联关系，而非数据泄露事实
Exposure 模块是整个报告的核心：
- 将Manifest权限映射到数据大类：位置、通讯录、摄像头、屏幕、剪贴板等；
- 匹配从APK中提取的网络端点，建立「权限类别 ↔ 目标主机」关联；
- 无匹配上传端点时，关联项置空。
这里最关键的认知边界：
该模块只建立静态关联，不抓包、不观测运行时流量。
报告里的“权限-域名关联”，只代表存在这种组合可能性，不等于该App已经把对应数据上传到这个服务器。
它的定位是：给安全人员标记高优先级核查项，而不是直接输出“数据泄露”结论。
快照参考文件：
core/src/commonMain/kotlin/app/noir/core/Exposure.kt
2.3 ApplyTest 处置测试：变更留痕、精准回滚，适配厂商定制ROM
针对权限修改、配置变更这类操作，项目在测试规范里明确约束：
- 执行失败：保留原始状态、错误日志，禁止生成虚假回滚记录；
- 执行成功：记录变更前原始模式，回滚时精确恢复到变更前状态；
Android碎片化严重，不同厂商ROM、系统版本对权限模型的实现存在差异。这套规范的价值，是强制保存前后状态快照，而不是只记录一句“执行成功”。
取证边界提醒：当前仅能读到测试用例设计意图，没有在真机上验证跨系统版本的回滚有效性。
快照参考文件：
cli/src/test/kotlin/app/noir/cli/ApplyTest.kt
2.4 操作边界隔离：离线分析、工具下载、激进动作分开管控
README 清晰区分三类独立行为，避免使用者混淆安全承诺：
- 审计分析结果：默认不上传；
- 初始化阶段：可选择下载ADB等依赖工具（存在联网行为）；
- 操作分级：默认仅生成报告，激进修改权限、卸载等高危操作需要用户显式开启。
重点避坑：
“审计数据不上传” ≠ 整个工具全程离线不联网；
“默认不卸载应用” ≠ 所有操作都不会删除应用。三类行为独立验收，不能互相推导安全承诺。
快照参考文件：README.md
三、L3 取证清单｜快照可复核边界（审计归档专用）
| 取证项 | 快照事实 |
|---|---|
| 固定提交 | 7b14d6c6ac751b291df3936844aa6291d3790fb5 |
| Git文件树 | 69 个文件条目 |
| 取证选取范围 | 有界取证选中30个文件，核验28个文件 |
| 克隆策略 | shallow=true；HEAD可达commit数=1；filter=blob:none |
| 完整性 | 选中集合覆盖率93.33%；非全仓库覆盖、非功能测试覆盖率 |
| 来源路由 | GH Proxy Primary + SafeNet 官方来源对照 |
| 运行动作 | 未扫描设备、未验证分类准确率、未执行权限处置、未验证回滚 |
| Manifest SHA-256 | 5d48800c0a3051bcc36feb3759fadadb9c79c773865bdca795f2181af2bfbe17 |
| 本地清单路径 | localfile://path?../repos/Verlintas__NOIR/.valhalla-l3-manifest.json |
| SafeNet账本链头 | 3fa55800a09530686f00c8ae3780dc816fa57e4daeb0ae9575b894af43628619 |
L3 定义：固定提交+选中文件证据链路可追溯；不证明：分类准确率、回滚在所有ROM有效、工具无漏洞、处置操作安全可控。文档中的测试规范，只是项目设计约定，不等于全部经过真机验证。
四、风险与许可红线（移动安全审计必审）
- 静态关联 ≠ 真实泄露
权限+域名匹配只是风险线索，不能单独作为泄露结论；如需定论，必须补充流量抓包、动态调试等动态证据。 - 系统变更风险
修改App权限会影响通知、投屏、后台服务等功能；即使存在回滚逻辑，也需要在对应机型、系统版本上实测，不能直接信任纸面回滚方案。 - 敏感报告管控风险
扫描输出的报告包含设备内App清单、权限、通信域名，属于敏感资产；仅允许在已授权设备上使用，严格控制报告分发、存储权限。 - 许可边界
项目代码为MIT协议，二次分发需保留版权声明；ADB、反编译工具、被分析APK，各自拥有独立授权约束，需要单独合规核验。
五、落地验证路线：分阶段使用，低风险优先
路线A：直接试用（安全审计标准流程）
- 优先在测试样机上，只开启报告生成模式，不执行任何权限变更；
- 抽样复核：人工核对包名分类、权限映射、提取域名，校验误报情况；
- 如需使用处置能力：单次执行单个变更动作，提前备份原始状态、命令输出、系统表现，执行后验证回滚是否生效；
- 对外输出结论：报告内容统一描述为「静态关联风险线索、待核查项」，禁止直接改写为“数据泄露”结论。
路线B：架构借鉴（自研移动审计平台）
如果你在搭建内部APK审计平台，可以优先借鉴这套设计范式：
- 风险模型分层：原始线索 → 关联映射 → 调查优先级，全程保留解释链路；
- 变更操作强制双记录：变更前快照 + 回滚动作；
- 操作分级隔离：只读分析默认安全，高危修改必须显式确认；
借鉴设计之后，需要自行适配国内ROM、应用市场包名规则，独立做误报率、回滚兼容性验收。
六、评测结论
NOIR 的亮点不在于强大的反编译能力，而在于它克制的边界设计：
它把Android静态审计里零散的权限、端点线索，封装成一份带解释、带处置方案、带回滚约束的调查报告。
它适合作为移动安全初筛、内部合规自查的辅助工具，用来提升审计效率、统一线索格式；
但它不能替代动态抓包、真机调试、专业逆向分析。能否在生产审计流程落地，核心取决于三点：分类规则误报管控、不同厂商ROM的回滚兼容性、审计报告的敏感权限管控。
文末补充说明（原创合规声明）
- 所有证据锚定在固定commit快照，Stars数值为快照采集时点数据，不代表近期新增趋势；
- 本文属于新建仓库补充评测，非GitHub周榜项目；
- 全文基于快照证据原创分析，无上游原文搬运；
- 评测属于Valhalla L3有界静态取证，全程只读，不连接真机、不解析真实APK；
- 本稿件属于十篇评测合集批次，已完成去重。
同系列延伸阅读：Agent Autoloop、Craft Anything、Spark、PR-Agent、Ghostty、Hyprland 开源证据评测
互动讨论：你在Android安全审计中，怎么区分静态权限线索和真实的数据泄露行为？
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/TunerT_TQ/article/details/170245565
